netdev - Re: [PATCH v4 4/9] vsock/virtio: Resize receive buffers so that each SKB fits in a 4K page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aWUFnZTkdOrZAest@sgarzare-redhat>
Date: Mon, 12 Jan 2026 15:48:11 +0100
From: Stefano Garzarella <sgarzare@...hat.com>
To: David Woodhouse <dwmw2@...radead.org>
Cc: Will Deacon <will@...nel.org>, linux-kernel@...r.kernel.org, 
	Keir Fraser <keirf@...gle.com>, Steven Moreland <smoreland@...gle.com>, 
	Frederick Mayle <fmayle@...gle.com>, Stefan Hajnoczi <stefanha@...hat.com>, 
	"Michael S. Tsirkin" <mst@...hat.com>, Jason Wang <jasowang@...hat.com>, 
	Eugenio Pérez <eperezma@...hat.com>, netdev@...r.kernel.org, virtualization@...ts.linux.dev
Subject: Re: [PATCH v4 4/9] vsock/virtio: Resize receive buffers so that each
 SKB fits in a 4K page

On Thu, Jan 08, 2026 at 05:33:42PM +0100, David Woodhouse wrote:
>On Thu, 2025-07-17 at 10:01 +0100, Will Deacon wrote:
>>
>> -#define VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE	(1024 * 4)
>> +/* Dimension the RX SKB so that the entire thing fits exactly into
>> + * a single 4KiB page. This avoids wasting memory due to alloc_skb()
>> + * rounding up to the next page order and also means that we
>> + * don't leave higher-order pages sitting around in the RX queue.
>> + */
>> +#define
>> VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE	SKB_WITH_OVERHEAD(1024 * 4)
>
>Should this be SKB_WITH_OVERHEAD()?

ehm, is what the patch is doing, no?

>
>Or should it subtract VIRTIO_VSOCK_SKB_HEADROOM instead?

Why?

IIRC the goal of the patch was to have an SKB that fit entirely on one 
page, to avoid wasting memory, so yes, we are reducing the payload a 
little bit (4K vs 4K - VIRTIO_VSOCK_SKB_HEADROOM - SKB_OVERHEAD), but we 
are also reducing segmentation.

>
>(And also, I have use cases where I want to expand this to 64KiB. Can I
>make it controllable with a sockopt? module param?)

I'm not sure about sockopt, because this is really device specific and 
can't be linked to a specific socket, since the device will pre-fill the 
queue with buffers that can be assigned to different sockets.

But yeah, perhaps a module parameter would suffice, provided that it can 
only be modified at load time, otherwise we would have to do something 
similar to NIC and ethtool, but I feel that would be too complicated for 
this use case.

Thanks,
Stefano