qemu-devel
[Top][All Lists]
Advanced

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

Re: Any reason VIRTQUEUE_MAX_SIZE is 1024? Can we increase this limit?


From: Jason Wang
Subject: Re: Any reason VIRTQUEUE_MAX_SIZE is 1024? Can we increase this limit?
Date: Mon, 10 Aug 2020 17:49:27 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0


On 2020/8/7 下午5:59, Stefan Hajnoczi wrote:
On Fri, Aug 07, 2020 at 11:35:08AM +0800, Jason Wang wrote:
On 2020/8/6 下午8:37, Stefan Hajnoczi wrote:
On Wed, Aug 05, 2020 at 08:13:29AM -0400, Michael S. Tsirkin wrote:
On Wed, Aug 05, 2020 at 01:11:07PM +0100, Stefan Hajnoczi wrote:
On Thu, Jul 30, 2020 at 07:46:09AM +0000, Yajun Wu wrote:
I'm doing iperf test on VIRTIO net through vhost-user(HW VDPA).
Find maximal acceptable tx_queue_size/rx_queue_size is 1024.
Basically increase queue size can get better RX rate for my case.

Can we increase the limit(VIRTQUEUE_MAX_SIZE) to 8192 to possibly gain better 
performance?
Hi,
The VIRTIO 1.1 specification says the maximum number of descriptors is
32768 for both split and packed virtqueues.

The vhost kernel code seems to support 32768.

The 1024 limit is an implementation limit in QEMU. Increasing it would
require QEMU code changes. For example, VIRTQUEUE_MAX_SIZE is used as
the size of arrays.

I can't think of a fundamental reason why QEMU needs to limit itself to
1024 descriptors. Raising the limit would require fixing up the code and
ensuring that live migration remains compatible with older versions of
QEMU.

Stefan
There's actually a reason for a limit: in theory the vq size
also sets a limit on the number of scatter/gather entries.
both QEMU and vhost can't handle a packet split over > 1k chunks.

We could add an extra limit for s/g size like block and scsi do,
this will need spec, guest and host side work.
Interesting, thanks for explaining! This could be made explicit by
changing the QEMU code to:

include/hw/virtio/virtio.h:#define VIRTQUEUE_MAX_SIZE IOV_MAX

Looking more closely at the vhost kernel code I see that UIO_MAXIOV is
used in some places but not in vhost_vring_set_num() (ioctl
VHOST_SET_VRING_NUM). Is there a reason why UIO_MAXIOV isn't enforced
when the application sets the queue size?

Actually three things:

1) queue size
2) #descriptors in a list
3) IOV size

Spec limit the 2) to 1) but 2) may not equal to 3).

So enforcing UIO_MAXIOV can not solve the problem completely.

For vhost-net, it depends on socket to build skb which requires an iov array
to work. We need remove this limitation by:

- build skb by vhost-net itself
- do piecewise copying

Then we're not limited with #iov and more and support up to what spec
supports.
If I understand correctly, you are saying vhost_net.ko does not support
more than UIO_MAXIOV descriptors today but it could be fixed as you
described.


Yes, but it needs major refactoring on vhost_net.

thanks



Thanks!

Stefan




reply via email to

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