qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [virtio-dev] Re: [PATCH RFC] virtio-net: enable configu


From: Jason Wang
Subject: Re: [Qemu-devel] [virtio-dev] Re: [PATCH RFC] virtio-net: enable configurable tx queue size
Date: Tue, 23 May 2017 14:24:44 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0



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








reply via email to

[Prev in Thread] Current Thread [Next in Thread]