On 10/13/25 18:54, Jakub Kicinski wrote:

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.

I think that would be quite unproductive considering that this series
has been around for 3 months already with no forward progress, and the
API was posted 6 months ago. I have a better idea, I'll shrink it down
by removing all unnecessary parts, that makes it much much simpler and
should detangle the effort from ethtool bits like Stan once suggested.
I've also been bothered for some time by it growing to 24 patches, it'll
help with that as well. And it'll be a good base to put all the netlink
configuration bits on top if necessary.

Also what's the resolution for the maintainers entry / cross posting?

I'm pretty much interested as well :) I've been CC'ing netdev as a
gesture of goodwill, that's despite you blocking an unrelated series
because of a rule you made up and retrospectively applied and belittling
my work after. It doesn't seem that you content with it either,
evidently from you blocking it again. I'm very curious what's that all
about? And since you're unwilling to deal with the series, maybe you'll
let other maintainers to handle it?

-- 
Pavel Begunkov