[PATCH 1/1] io_uring zcrx: add MAINTAINERS entry

[PATCH 1/1] io_uring zcrx: add MAINTAINERS entry

[David Wei]

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.

With this updated entry, folks running get_maintainer.pl on patches that
touch io_uring/zcrx.* will know to send it to netdev@ as well.

Note that this doesn't mean all changes require explicit acks from
netdev; this is purely for wider visibility and for other contributors
to know where to send patches.

[1]: https://lore.kernel.org/io-uring/989528e611b51d71fb712691ebfb76d2059ba561.1755461246.git.asml.silence@gmail.com/

Signed-off-by: David Wei <dw@davidwei.uk>
---
 MAINTAINERS | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 545a4776795e..067eebbff09b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13111,6 +13111,15 @@ F:	include/uapi/linux/io_uring.h
 F:	include/uapi/linux/io_uring/
 F:	io_uring/
 
+IO_URING ZCRX
+M:	Pavel Begunkov <asml.silence@gmail.com>
+L:	io-uring@vger.kernel.org
+L:	netdev@vger.kernel.org
+T:	git https://github.com/isilence/linux.git zcrx/for-next
+T:	git git://git.kernel.dk/linux-block
+S:	Maintained
+F:	io_uring/zcrx.*
+
 IPMI SUBSYSTEM
 M:	Corey Minyard <corey@minyard.net>
 L:	openipmi-developer@lists.sourceforge.net (moderated for non-subscribers)
-- 
2.47.3

Re: [PATCH 1/1] io_uring zcrx: add MAINTAINERS entry

[Mina Almasry]

On Tue, Oct 21, 2025 at 1:29 PM David Wei <dw@davidwei.uk> 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.
>
> With this updated entry, folks running get_maintainer.pl on patches that
> touch io_uring/zcrx.* will know to send it to netdev@ as well.
>
> Note that this doesn't mean all changes require explicit acks from
> netdev; this is purely for wider visibility and for other contributors
> to know where to send patches.
>
> [1]: https://lore.kernel.org/io-uring/989528e611b51d71fb712691ebfb76d2059ba561.1755461246.git.asml.silence@gmail.com/
>
> Signed-off-by: David Wei <dw@davidwei.uk>

Seems fine to me,

Reviewed-by: Mina Almasry <almasrymina@google.com>

-- 
Thanks,
Mina

Re: [PATCH 1/1] io_uring zcrx: add MAINTAINERS entry

[Jakub Kicinski]

On Tue, 21 Oct 2025 13:29:44 -0700 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.
> 
> With this updated entry, folks running get_maintainer.pl on patches that
> touch io_uring/zcrx.* will know to send it to netdev@ as well.
> 
> Note that this doesn't mean all changes require explicit acks from
> netdev; this is purely for wider visibility and for other contributors
> to know where to send patches.

Thanks David! Not sure how to read the double T, I expected the entry
to be more of a copy of the existing IO_URING one. But it's a step
forward so if Jens is happy with this:

Acked-by: Jakub Kicinski <kuba@kernel.org>

Re: [PATCH 1/1] io_uring zcrx: add MAINTAINERS entry

[Pavel Begunkov]

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.

In general, if I'm as a patch submitter asked to follow rules, it's
only natural to assume there is a process and rules maintainers keep to
as well. And I'd believe that includes unbiased treatment and technical
merit rather than decision based on mood of the day.

-- 
Pavel Begunkov

Re: [PATCH 1/1] io_uring zcrx: add MAINTAINERS entry

[Jens Axboe]

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

Re: [PATCH 1/1] io_uring zcrx: add MAINTAINERS entry

[Pavel Begunkov]

On 10/22/25 14:17, Jens Axboe wrote:
> 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

Can you point out where that was requested dated before the series in
question? Because as far as I know, only CC'ing was mentioned and
only as a question, for which I proposed a fairly standard way of
dealing with it by introducing API and agreeing on any changes to that,
and got no reply. Even then, I was CC'ing netdev for changes that might
be interesting to netdev, that includes the blocked series.

> 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.

Not really, solely depends on the reply.

> And honestly, nobody wants to deal with that, if

Understandable, but you're making it sound like I started by
throwing accusations and not the other way around. But it's
true that I never wanted to deal with it.

> 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.
> 

-- 
Pavel Begunkov

Re: [PATCH 1/1] io_uring zcrx: add MAINTAINERS entry

[Keith Busch]

On Tue, Oct 21, 2025 at 01:29:44PM -0700, David Wei wrote:
> +IO_URING ZCRX
> +M:	Pavel Begunkov <asml.silence@gmail.com>
> +L:	io-uring@vger.kernel.org
> +L:	netdev@vger.kernel.org
> +T:	git https://github.com/isilence/linux.git zcrx/for-next
> +T:	git git://git.kernel.dk/linux-block

Is git.kernel.dk still correct? Just mentioning it since Jens recently
changed io-uring's tree to git.kernel.org. I see that kernel.dk is
currently up again, so maybe it's fine.

Re: [PATCH 1/1] io_uring zcrx: add MAINTAINERS entry

[Jens Axboe]

On 10/22/25 8:25 AM, Pavel Begunkov wrote:
> On 10/22/25 14:17, Jens Axboe wrote:
>> 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
> 
> Can you point out where that was requested dated before the series in
> question? Because as far as I know, only CC'ing was mentioned and
> only as a question, for which I proposed a fairly standard way of
> dealing with it by introducing API and agreeing on any changes to that,
> and got no reply. Even then, I was CC'ing netdev for changes that might
> be interesting to netdev, that includes the blocked series.

Not interested in digging out those other discussions, but Mina had a
patch back in August, and there was the previous discussion on the big
patchset. At least I very much understood it as netdev wanting to be
CC'ed, and the straight forward way to always have that is to make it
explicit in MAINTAINERS.

>> 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.
> 
> Not really, solely depends on the reply.

Well, statistically based on recent and earlier replies in those
threads, if I was on that side, I'd say that would be a fair assumption.

>> And honestly, nobody wants to deal with that, if
> 
> Understandable, but you're making it sound like I started by
> throwing accusations and not the other way around. But it's
> true that I never wanted to deal with it.

Honestly I don't even know where this all started, but it hasn't been
going swimmingly the last few months would be my assessment.

My proposal is to put all of this behind us and move forward in a
productive manner. There's absolutely nothing to be gained from
continuing down the existing path of arguing about who did what and why,
and frankly I have zero inclination to participate in that. It should be
in everybody's best interest to move forward, productively. And if that
starts with a simple MAINTAINERS entry, that seems like a good place to
start. So _please_, can we do that?

-- 
Jens Axboe

Re: [PATCH 1/1] io_uring zcrx: add MAINTAINERS entry

[Jens Axboe]

On 10/22/25 8:30 AM, Keith Busch wrote:
> On Tue, Oct 21, 2025 at 01:29:44PM -0700, David Wei wrote:
>> +IO_URING ZCRX
>> +M:	Pavel Begunkov <asml.silence@gmail.com>
>> +L:	io-uring@vger.kernel.org
>> +L:	netdev@vger.kernel.org
>> +T:	git https://github.com/isilence/linux.git zcrx/for-next
>> +T:	git git://git.kernel.dk/linux-block
> 
> Is git.kernel.dk still correct? Just mentioning it since Jens recently
> changed io-uring's tree to git.kernel.org. I see that kernel.dk is
> currently up again, so maybe it's fine.

Yeah true, it is not. I missed that. David, see the io_uring MAINTAINERS
entry for the correct URLs. But I can just hand edit that, no need to
resend anything.

-- 
Jens Axboe

Re: [PATCH 1/1] io_uring zcrx: add MAINTAINERS entry

[Pavel Begunkov]

On 10/22/25 15:34, Jens Axboe wrote:
> On 10/22/25 8:25 AM, Pavel Begunkov wrote:
>> On 10/22/25 14:17, Jens Axboe wrote:
>>> 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
>>
>> Can you point out where that was requested dated before the series in
>> question? Because as far as I know, only CC'ing was mentioned and
>> only as a question, for which I proposed a fairly standard way of
>> dealing with it by introducing API and agreeing on any changes to that,
>> and got no reply. Even then, I was CC'ing netdev for changes that might
>> be interesting to netdev, that includes the blocked series.
> 
> Not interested in digging out those other discussions, but Mina had a
> patch back in August, and there was the previous discussion on the big

If August, I'm pretty sure you're referring to one of the
replies / follow ups after the mentioned series.

> patchset. At least I very much understood it as netdev wanting to be
> CC'ed, and the straight forward way to always have that is to make it
> explicit in MAINTAINERS.
> 
>>> 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.
>>
>> Not really, solely depends on the reply.
> 
> Well, statistically based on recent and earlier replies in those
> threads, if I was on that side, I'd say that would be a fair assumption.
> 
>>> And honestly, nobody wants to deal with that, if
>>
>> Understandable, but you're making it sound like I started by
>> throwing accusations and not the other way around. But it's
>> true that I never wanted to deal with it.
> 
> Honestly I don't even know where this all started, but it hasn't been
> going swimmingly the last few months would be my assessment.
> 
> My proposal is to put all of this behind us and move forward in a
> productive manner. There's absolutely nothing to be gained from
> continuing down the existing path of arguing about who did what and why,
> and frankly I have zero inclination to participate in that. It should be
> in everybody's best interest to move forward, productively. And if that
> starts with a simple MAINTAINERS entry, that seems like a good place to
> start. So _please_, can we do that?

I'm convinced it's not going to help with the work being
blocked or the aforementioned issues, but ok, let's have it
your way.

-- 
Pavel Begunkov

Re: [PATCH 1/1] io_uring zcrx: add MAINTAINERS entry

[Jens Axboe]

On Tue, 21 Oct 2025 13:29:44 -0700, 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.
> 
> With this updated entry, folks running get_maintainer.pl on patches that
> touch io_uring/zcrx.* will know to send it to netdev@ as well.
> 
> [...]

Applied, thanks!

[1/1] io_uring zcrx: add MAINTAINERS entry
      commit: 060aa0b0c26c9e88cfc1433fab3d0145700e8247

Best regards,
-- 
Jens Axboe