Re: [PATCH RFC 4/4] vsock/virtio: increase RX buffer size to 64 KiB

From: Jason Wang <jasowang@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Cc: netdev@vger.kernel.org, Stefan Hajnoczi <stefanha@redhat.com>,
	kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Stefano Garzarella <sgarzare@redhat.com>
Subject: Re: [PATCH RFC 4/4] vsock/virtio: increase RX buffer size to 64 KiB
Date: Mon, 8 Apr 2019 14:35:37 +0800	[thread overview]
Message-ID: <947d9806-f661-a739-5752-ca6cd6500bd2@redhat.com> (raw)
In-Reply-To: <20190405084414.GE25152@stefanha-x1.localdomain>

On 2019/4/5 下午4:44, Stefan Hajnoczi wrote:
> On Thu, Apr 04, 2019 at 12:58:38PM +0200, Stefano Garzarella wrote:
>> In order to increase host -> guest throughput with large packets,
>> we can use 64 KiB RX buffers.
>>
>> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
>> ---
>>   include/linux/virtio_vsock.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/virtio_vsock.h b/include/linux/virtio_vsock.h
>> index 6d7a22cc20bf..43cce304408e 100644
>> --- a/include/linux/virtio_vsock.h
>> +++ b/include/linux/virtio_vsock.h
>> @@ -10,7 +10,7 @@
>>   #define VIRTIO_VSOCK_DEFAULT_MIN_BUF_SIZE	128
>>   #define VIRTIO_VSOCK_DEFAULT_BUF_SIZE		(1024 * 256)
>>   #define VIRTIO_VSOCK_DEFAULT_MAX_BUF_SIZE	(1024 * 256)
>> -#define VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE	(1024 * 4)
>> +#define VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE	(1024 * 64)
> This patch raises rx ring memory consumption from 128 * 4KB = 512KB to
> 128 * 64KB = 8MB.
>
> Michael, Jason: Any advice regarding rx/tx ring sizes and buffer sizes?
>
> Depending on rx ring size and the workload's packet size, different
> values might be preferred.
>
> This could become a tunable in the future.  It determines the size of
> the guest driver's rx buffers.

In virtio-net, we have mergeable rx buffer and estimate the rx buffer 
size through EWMA.

That's another reason I suggest to squash the vsock codes into virtio-net.

Thanks