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: <727f0c1f-8ffd-46ba-936b-28db32463c39@uwaterloo.ca>
Date: Sat, 13 Sep 2025 12:03:53 -0400
From: Martin Karsten <mkarsten@...terloo.ca>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Samiullah Khawaja <skhawaja@...gle.com>,
 "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 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.

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.

Thanks,
Martin