netdev - Re: [PATCH net-next v9 0/2] Add support to do threaded napi busy poll

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAAywjhT7p=6MHw6S5SBmq5aPt8QaxCewpUGNQdTbur=9SfLFsA@mail.gmail.com>
Date: Mon, 15 Sep 2025 09:26:54 -0700
From: Samiullah Khawaja <skhawaja@...gle.com>
To: Martin Karsten <mkarsten@...terloo.ca>
Cc: Jakub Kicinski <kuba@...nel.org>, "David S . Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, almasrymina@...gle.com, 
	willemb@...gle.com, Joe Damato <joe@...a.to>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v9 0/2] Add support to do threaded napi busy poll

On Sat, Sep 13, 2025 at 9:03 AM Martin Karsten <mkarsten@...terloo.ca> wrote:
>
> On 2025-09-12 22:07, Jakub Kicinski wrote:
> > On Fri, 12 Sep 2025 04:08:21 -0400 Martin Karsten wrote:
> >> The xsk_rr tool represents a specific (niche) case that is likely
> >> relevant, but a comprehensive evaluation would also include mainstream
> >> communication patterns using an existing benchmarking tool. While
> >> resource usage is claimed to not be a concern in this particular use
> >> case, it might be quite relevant in other use cases and as such, should
> >> be documented.
> >
> > Thanks a lot for working on this.
> >
> > Were you able to replicate the results? Would you be willing to perhaps
> > sketch out a summary of your findings that we could use as the cover
> > letter / addition to the docs?
> >
> > I agree with you that the use cases for this will be very narrow (as
> > are the use cases for threaded NAPI in the first place, don't get me
> > started). For forwarding use cases, however, this may be the only
> > option for busy polling, unfortunately :(
>
> Yes, to the extent possible (different, old hardware) I am seeing
> similar results for similar test cases.
Thanks for reproducing the results.
>
> In terms of summary, I would like to see a qualifying statement added
> prominently to the cover letter, such as:
>
> Note well that threaded napi busy-polling has not been shown to yield
> efficiency or throughput benefits. In contrast, dedicating an entire
> core to busy-polling one NAPI (NIC queue) is rather inefficient.
> However, in certain specific use cases, this mechanism results in lower
> packet processing latency. The experimental testing reported here only
> covers those use cases and does not present a comprehensive evaluation
> of threaded napi busy-polling.
Sounds good. I will add this to the cover letter in next revision.
>
> Thanks,
> Martin
>