Re: [RFC v1 00/22] Large rx buffer support for zcrx

On 7/31/25 20:34, Mina Almasry wrote:

On Wed, Jul 30, 2025 at 8:50 AM Stanislav Fomichev [off-list ref] wrote:

...>> For devmem (and same for iou?), we want an option to derive (2) from (1):

quoted

page pools with larger chunks need to generate larger rx entries.

To be honest I'm not following. #1 and #2 seem the same to me.
rx-buf-len is just the size of each rx buffer posted to the NIC.

With pp_params.order = 0 (most common configuration today), rx-buf-len
== 4K. Regardless of MTU. With pp_params.order=1, I'm guessing 8K
then, again regardless of MTU.

I think if the user has not configured rx-buf-len, the driver is
probably free to pick whatever it wants and that can be a derivative
of the MTU.

When the rx-buf-len is configured by the user, I assume the driver
puts aside all MTU-related heuristics (if it has them) and uses
whatever the userspace specified.

Note that the memory provider may reject the request. For example
iouring and pages providers can only do page-order allocations. Devmem
can in theory do any byte-aligned allocation, since gen_pool doesn't
have a restriction AFAIR.

It's trivial to add sub-page and/or non-pow2 allocations to zcrx,
but the size needs to be uniform and decided on at registration.

-- 
Pavel Begunkov