On 10/14/25 05:41, Mina Almasry wrote:

On Mon, Oct 13, 2025 at 10:54 AM Jakub Kicinski [off-list ref] wrote:

quoted

On Mon, 13 Oct 2025 15:54:02 +0100 Pavel Begunkov wrote:

quoted

Jakub Kicinski (20):
   docs: ethtool: document that rx_buf_len must control payload lengths
   net: ethtool: report max value for rx-buf-len
   net: use zero value to restore rx_buf_len to default
   net: clarify the meaning of netdev_config members
   net: add rx_buf_len to netdev config
   eth: bnxt: read the page size from the adapter struct
   eth: bnxt: set page pool page order based on rx_page_size
   eth: bnxt: support setting size of agg buffers via ethtool
   net: move netdev_config manipulation to dedicated helpers
   net: reduce indent of struct netdev_queue_mgmt_ops members
   net: allocate per-queue config structs and pass them thru the queue
     API
   net: pass extack to netdev_rx_queue_restart()
   net: add queue config validation callback
   eth: bnxt: always set the queue mgmt ops
   eth: bnxt: store the rx buf size per queue
   eth: bnxt: adjust the fill level of agg queues with larger buffers
   netdev: add support for setting rx-buf-len per queue
   net: wipe the setting of deactived queues
   eth: bnxt: use queue op config validate
   eth: bnxt: support per queue configuration of rx-buf-len

I'd like to rework these a little bit.
On reflection I don't like the single size control.
Please hold off.

FWIW when I last looked at this I didn't like that the size control
seemed to control the size of the allocations made from the pp, but
not the size actually posted to the NIC.

I.e. in the scenario where the driver fragments each pp buffer into 2,
and the user asks for 8K rx-buf-len, the size actually posted to the
NIC would have actually been 4K (8K / 2 for 2 fragments).

Not sure how much of a concern this really is. I thought it would be
great if somehow rx-buf-len controlled the buffer sizes actually
posted to the NIC, because that what ultimately matters, no (it ends
up being the size of the incoming frags)? Or does that not matter for
some reason I'm missing?

Maybe we should just make a rule that if hardware doesn't support
the given size, qops should fail, but ultimately the userspace
should be able to handle it either way as gro is packing not
100% reliably.

-- 
Pavel Begunkov