public inbox for io-uring@vger.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH net-next v4 00/24][pull request] Queue configs and large buffer providers
       [not found] <cover.1760364551.git.asml.silence@gmail.com>
@ 2025-10-13 15:03 ` Pavel Begunkov
       [not found] ` <20251013105446.3efcb1b3@kernel.org>
  1 sibling, 0 replies; 2+ messages in thread
From: Pavel Begunkov @ 2025-10-13 15:03 UTC (permalink / raw)
  To: netdev
  Cc: Andrew Lunn, Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni,
	Simon Horman, Donald Hunter, Michael Chan, Pavan Chebbi,
	Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
	Joshua Washington, Harshitha Ramamurthy, Jian Shen, Salil Mehta,
	Jijie Shao, Sunil Goutham, Geetha sowjanya, Subbaraya Sundeep,
	hariprasad, Bharat Bhushan, Saeed Mahameed, Tariq Toukan,
	Mark Bloch, Leon Romanovsky, Alexander Duyck, kernel-team,
	Ilias Apalodimas, Joe Damato, David Wei, Willem de Bruijn,
	Mina Almasry, Breno Leitao, Dragos Tatulea, linux-kernel,
	linux-doc, linux-rdma, Jonathan Corbet, io-uring

On 10/13/25 15:54, Pavel Begunkov wrote:

Forgot to CC io_uring

> Add support for per-queue rx buffer length configuration based on [2]
> and basic infrastructure for using it in memory providers like
> io_uring/zcrx. Note, it only includes net/ patches and leaves out
> zcrx to be merged separately. Large rx buffers can be beneficial with
> hw-gro enabled cards that can coalesce traffic, which reduces the
> number of frags traversing the network stack and resuling in larger
> contiguous chunks of data given to the userspace.

Same note as the last time, not great that it's over the 15 patches,
but I don't see a good way to shrink it considering that the original
series [2] is 22 patches long, and I'll somehow need to pull it it
into the io_uring tree after. Please let me know if there is a strong
feeling about that, and/or what would the preferred way be.

-- 
Pavel Begunkov


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH net-next v4 00/24][pull request] Queue configs and large buffer providers
       [not found] ` <20251013105446.3efcb1b3@kernel.org>
@ 2025-10-14 12:46   ` Pavel Begunkov
  0 siblings, 0 replies; 2+ messages in thread
From: Pavel Begunkov @ 2025-10-14 12:46 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: netdev, Andrew Lunn, davem, Eric Dumazet, Paolo Abeni,
	Simon Horman, Donald Hunter, Michael Chan, Pavan Chebbi,
	Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
	Joshua Washington, Harshitha Ramamurthy, Jian Shen, Salil Mehta,
	Jijie Shao, Sunil Goutham, Geetha sowjanya, Subbaraya Sundeep,
	hariprasad, Bharat Bhushan, Saeed Mahameed, Tariq Toukan,
	Mark Bloch, Leon Romanovsky, Alexander Duyck, kernel-team,
	Ilias Apalodimas, Joe Damato, David Wei, Willem de Bruijn,
	Mina Almasry, Breno Leitao, Dragos Tatulea, linux-kernel,
	linux-doc, linux-rdma, Jonathan Corbet, io-uring

On 10/13/25 18:54, Jakub Kicinski 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.

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-10-14 12:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <cover.1760364551.git.asml.silence@gmail.com>
2025-10-13 15:03 ` [PATCH net-next v4 00/24][pull request] Queue configs and large buffer providers Pavel Begunkov
     [not found] ` <20251013105446.3efcb1b3@kernel.org>
2025-10-14 12:46   ` Pavel Begunkov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox