Re: [PATCH net-next v4 00/24][pull request] Queue configs and large buffer providers

[Pavel Begunkov]

On 10/14/25 05:41, Mina Almasry wrote:
> On Mon, Oct 13, 2025 at 10:54 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
> > On Mon, 13 Oct 2025 15:54:02 +0100 Pavel Begunkov wrote:
> > > 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