[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <832b03de-6b59-4a07-b7ea-51492c4cca7e@kernel.dk>
Date: Wed, 22 Oct 2025 07:17:45 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Pavel Begunkov <asml.silence@...il.com>, David Wei <dw@...idwei.uk>,
io-uring@...r.kernel.org, netdev@...r.kernel.org
Cc: Jakub Kicinski <kuba@...nel.org>, Mina Almasry <almasrymina@...gle.com>
Subject: Re: [PATCH 1/1] io_uring zcrx: add MAINTAINERS entry
On 10/22/25 5:38 AM, Pavel Begunkov wrote:
> On 10/21/25 21:29, David Wei wrote:
>> Same as [1] but also with netdev@ as an additional mailing list.
>> io_uring zero copy receive is of particular interest to netdev
>> participants too, given its tight integration to netdev core.
>
> David, I can guess why you sent it, but it doesn't address the bigger
> problem on the networking side. Specifically, why patches were blocked
> due to a rule that had not been voiced before and remained blocked even
> after pointing this out? And why accusations against me with the same
> circumstances, which I equate to defamation, were left as is without
> any retraction? To avoid miscommunication, those are questions to Jakub
> and specifically about the v3 of the large buffer patchset without
> starting a discussion here on later revisions.
>
> Without that cleared, considering that compliance with the new rule
> was tried and lead to no results, this behaviour can only be accounted
> to malice, and it's hard to see what cooperation is there to be had as
> there is no indication Jakub is going to stop maliciously blocking
> my work.
The netdev side has been pretty explicit on wanting a MAINTAINERS entry
so that they see changes. I don't think it's unreasonable to have that,
and it doesn't mean that they need to ack things that are specific to
zcrx. Nobody looks at all the various random lists, giving them easier
insight is a good thing imho. I think we all agree on that.
Absent that change, it's also not unreasonable for that side to drag
their feet a bit on further changes. Could the communication have been
better on that side? Certainly yes. But it's hard to blame them too much
on that front, as any response would have predictably yielded an
accusatory reply back. And honestly, nobody wants to deal with that, if
they can avoid it. Since there's plenty of other work to do and patches
to review which is probably going to be more pleasurable, then people go
and do that.
The patch David sent is a way to at least solve one part of the issue,
and imho something like that is a requirement for anything further to be
considered. Let's perhaps roll with that and attempt to help ourselves
here, by unblocking that part.
Are you fine with the patch? If so, I will queue it up and let's please
move on from beating this dead horse.
--
Jens Axboe
Powered by blists - more mailing lists