? 2021/8/11 ??7:04, Eli Cohen ??:> On Wed, Aug 11, 2021 at 04:37:44PM +0800, Jason Wang wrote:
>> ? 2021/8/11 ??3:53, Eli Cohen ??:
>>>> One thing need to solve for mq is that the:
>>>>
>>>>
>>>>> +static u16 ctrl_vq_idx(struct mlx5_vdpa_dev *mvdev)
>>>>> +{
>>>>> +? ? ?return 2 * mlx5_vdpa_max_qps(mvdev->max_vqs);
>>>>> +}
>>>> We should handle the case when MQ is supported by the device
but not the
>>>> driver.
>>>>
>>>> E.g in the case when we have 2 queue pairs:
>>>>
>>>> When MQ is enabled, cvq is queue 4
>>>>
>>>> When MQ is not enabled, cvq is queue 2
>>>>
>>> There's some issue with this. I get callbacks targeting
specific
>>> virtqueues before features negotiation has been completed.
>>>
>>> Specifically, I get set_vq_cb() calls. At this point I must know
the
>>> control vq index.
>>
>> So I think we need do both:
>>
>> 1) At one hand, it's a bug for the userspace to use vq_index before
feature
>> is negotiated
>>
>> (looks like a bug in my cvq series that will call SET_VRING_CALL before
>> feature is negotiate, which I will look).
>>
>> 2) At the other hand, the driver should be able to deal with that
>>
> All I can do is drop callbacks for VQs before features negotation has
> been completed.
Or just leave queue index 0, 1 work.
Since it is not expected to be changed.
>
>>> I think the CVQ index must not depend on the negotiated features
but
>>> rather depend of the value the device driver provides in the call
to
>>> _vdpa_register_device().
>>
>> At the virtio level, it's too late to change that and it breaks the
backward
>> compatibility.
>>
>> But at the vDPA level, the under layer device can map virtio cvq to any
of
>> it's virtqueue.
>>
>> E.g map cvq (index 2) to mlx5 cvq (the last).
>>
> I am not following you here. I still don't know what index is cvq.
Right, we still need to wait for the feature being negotiated in order
to proceed.
Thanks
>
>> Thanks
>>
>>