Re: [Qemu-devel] [virtio-dev] Re: [virtio-dev] Re: [PATCH v1] virtio-net: enable configurable tx queue size

[Wei Wang <wei.w.wang@intel.com>]

On 06/13/2017 05:04 PM, Jason Wang wrote:
>
>
> On 2017年06月13日 15:17, Wei Wang wrote:
>> On 06/13/2017 02:29 PM, Jason Wang wrote:
>>> The issue is what if there's a mismatch of max #sgs between qemu and
>>>>>> When the vhost backend is used, QEMU is not involved in the data 
>>>>>> path.
>>>>>> The vhost backend
>>>>>> directly gets what is offered by the guest from the vq. Why would
>>>>>> there be a mismatch of
>>>>>> max #sgs between QEMU and vhost, and what is the QEMU side max #sgs
>>>>>> used for? Thanks.
>>>>> You need query the backend max #sgs in this case at least. no? If not
>>>>> how do you know the value is supported by the backend?
>>>>>
>>>>> Thanks
>>>>>
>>>> Here is my thought: vhost backend has already been supporting 1024 
>>>> sgs,
>>>> so I think it might not be necessary to query the max sgs that the 
>>>> vhost
>>>> backend supports. In the setup phase, when QEMU detects the backend is
>>>> vhost, it assumes 1024 max sgs is supported, instead of giving an 
>>>> extra
>>>> call to query.
>>>
>>> We can probably assume vhost kernel supports up to 1024 sgs. But how 
>>> about for other vhost-user backends?
>>>
>> So far, I haven't seen any vhost backend implementation supporting 
>> less than 1024 sgs.
>
> Since vhost-user is an open protocol we can not check each 
> implementation (some may be even close sourced). For safety, we need 
> an explicit clarification on this.
>
>>
>>
>>> And what you said here makes me ask one of my questions in the past:
>>>
>>> Do we have plan to extend 1024 to a larger value or 1024 looks good 
>>> for the future years? If we only care about 1024, there's even no 
>>> need for a new config filed, a feature flag is more than enough. If 
>>> we want to extend it to e.g 2048, we definitely need to query vhost 
>>> backend's limit (even for vhost-kernel).
>>>
>>
>> According to virtio spec (e.g. 2.4.4), unreasonably large descriptors 
>> are
>> not encouraged to be used by the guest. If possible, I would suggest 
>> to use
>> 1024 as the largest number of descriptors that the guest can chain, 
>> even when
>> we have larger queue size in the future. That is,
>> if (backend == QEMU backend)
>>     config.max_chain_size = 1023 (defined by the qemu backend 
>> implementation);
>> else if (backend == vhost)
>>     config.max_chain_size = 1024;
>>
>> It is transparent to the guest. From the guest's point of view, all 
>> it knows is a value
>> given to him via reading config.max_chain_size.
>
> So not transparent actually, guest at least guest need to see and 
> check for this. So the question still, since you only care about two 
> cases in fact:
>
> - backend supports 1024
> - backend supports <1024 (qemu or whatever other backends)
>
> So it looks like a new feature flag is more than enough. If 
> device(backends) support this feature, it can make sure 1024 sgs is 
> supported?
>

That wouldn't be enough. For example, QEMU3.0 backend supports 
max_chain_size=1023,
while QEMU4.0 backend supports max_chain_size=1021. How would the guest know
the max size with the same feature flag? Would it still chain 1023 
descriptors with QEMU4.0?

Best,
Wei