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

[Jason Wang <jasowang@redhat.com>]

On 2017年05月23日 13:15, Wei Wang wrote:
> On 05/23/2017 10:04 AM, Jason Wang wrote:
>>
>>
>> On 2017年05月22日 19:52, Wei Wang wrote:
>>> On 05/20/2017 04:42 AM, Michael S. Tsirkin wrote:
>>>> On Fri, May 19, 2017 at 10:32:19AM +0800, Wei Wang wrote:
>>>>> This patch enables the virtio-net tx queue size to be configurable
>>>>> between 256 (the default queue size) and 1024 by the user. The queue
>>>>> size specified by the user should be power of 2.
>>>>>
>>>>> Setting the tx queue size to be 1024 requires the guest driver to
>>>>> support the VIRTIO_NET_F_MAX_CHAIN_SIZE feature.
>>>> This should be a generic ring feature, not one specific to virtio net.
>>> OK. How about making two more changes below:
>>>
>>> 1) make the default tx queue size = 1024 (instead of 256).
>>
>> As has been pointed out, you need compat the default value too in 
>> this case.
>
> The driver gets the size info from the device, then would it cause any
> compatibility issue if we change the default ring size to 1024 in the
> vhost case? In other words, is there any software (i.e. any virtio-net 
> driver)
> functions based on the assumption of 256 queue size?

I don't know. But is it safe e.g we migrate from 1024 to an older qemu 
with 256 as its queue size?

>
> For live migration, the queue size that is being used will also be 
> transferred
> to the destination.
>
>>
>>> We can reduce the size (to 256) if the MAX_CHAIN_SIZE feature
>>> is not supported by the guest.
>>> In this way, people who apply the QEMU patch can directly use the
>>> largest queue size(1024) without adding the booting command line.
>>>
>>> 2) The vhost backend does not use writev, so I think when the vhost
>>> backed is used, using 1024 queue size should not depend on the
>>> MAX_CHAIN_SIZE feature.
>>
>> But do we need to consider even larger queue size now?
>
> Need Michael's feedback on this. Meanwhile, I'll get the next version of
> code ready and check if larger queue size would cause any corner case.

The problem is, do we really need a new config filed for this? Or just 
introduce a flag which means "I support up to 1024 sgs" is sufficient?

>
>>
>> Btw, I think it's better to draft a spec patch.
>>
>
> I think it should be easier to draft the spec patch when the code is
> almost done.

Maybe both.

Thanks

>
>
> Best,
> Wei
>
>
>
>