netdev - Re: [PATCH net-next v5 0/4] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <680fc1f210fdf_246a60294b2@willemb.c.googlers.com.notmuch>
Date: Mon, 28 Apr 2025 13:59:14 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Joe Damato <jdamato@...tly.com>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: Martin Karsten <mkarsten@...terloo.ca>, 
 Samiullah Khawaja <skhawaja@...gle.com>, 
 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, 
 netdev@...r.kernel.org
Subject: Re: [PATCH net-next v5 0/4] Add support to do threaded napi busy poll

Joe Damato wrote:
> On Mon, Apr 28, 2025 at 12:52:11PM -0400, Willem de Bruijn wrote:
> > Martin Karsten wrote:
> > > On 2025-04-24 16:02, Samiullah Khawaja wrote:
> 
> > Ack on documentation of the pros/cons.
> 
> In my mind this includes documenting CPU usage which I know is
> considered as "non-goal" of this series. It can be a "non-goal" but
> it is still very relevant to the conversation and documentation.
> 
> > There is also a functional argument for this feature. It brings
> > parity with userspace network stacks like DPDK and Google's SNAP [1].
> > These also run packet (and L4+) network processing on dedicated cores,
> > and by default do so in polling mode. An XDP plane currently lacks
> > this well understood configuration. This brings it closer to parity.
> 
> It would be good if this could also be included in the cover letter,
> I think, possibly with example use cases.
> 
> > Users of such advanced environments can be expected to be well
> > familiar with the cost of polling. The cost/benefit can be debated
> > and benchmarked for individual applications. But there clearly are
> > active uses for polling, so I think it should be an operating system
> > facility.
> 
> You mention users of advanced environments, but I think it's
> important to consider the average user who is not necessarily a
> kernel programmer.
> 
> Will that user understand that not all apps support this? Or will
> they think that they can simply run a few YNL commands burning CPUs at
> 100% for apps that don't even support this thinking they are making
> their networking faster?

Busy polling can already be configured through sysfs.

I have not seen any conversations where this is suggested to non
expert users. I don't think this will be different.

But we can and should definitely increase the confidence by making
sure that any documentation of the feature contains a clear warning to
the impact and that this is for expert users only.

> I think providing a mechanism to burn CPU cores at 100% CPU by
> enabling threaded busy poll has serious consequences on power
> consumption, cooling requirements, and, errr, earth. I don't think
> it's a decision to be taken lightly.

Good point.