netdev - RE: [RFC PATCH 1/2] net: Add sysfs files for threaded NAPI.

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <MWHPR11MB129321759864A20827BE04DDF1469@MWHPR11MB1293.namprd11.prod.outlook.com>
Date: Thu, 25 May 2023 00:16:54 +0000
From: "Nambiar, Amritha" <amritha.nambiar@...el.com>
To: Jakub Kicinski <kuba@...nel.org>, Sebastian Andrzej Siewior
	<bigeasy@...utronix.de>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Eric Dumazet
	<edumazet@...gle.com>, "Kanzenbach, Kurt" <kurt.kanzenbach@...utronix.de>,
	Paolo Abeni <pabeni@...hat.com>, Thomas Gleixner <tglx@...utronix.de>,
	"Samudrala, Sridhar" <sridhar.samudrala@...el.com>
Subject: RE: [RFC PATCH 1/2] net: Add sysfs files for threaded NAPI.

> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Wednesday, May 24, 2023 9:25 PM
> To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> Cc: netdev@...r.kernel.org; Eric Dumazet <edumazet@...gle.com>;
> Kanzenbach, Kurt <kurt.kanzenbach@...utronix.de>; Paolo Abeni
> <pabeni@...hat.com>; Thomas Gleixner <tglx@...utronix.de>
> Subject: Re: [RFC PATCH 1/2] net: Add sysfs files for threaded NAPI.
> 
> On Wed, 24 May 2023 13:12:58 +0200 Sebastian Andrzej Siewior wrote:
> > I've been looking into threaded NAPI. One awkward thing to do is
> > to figure out the thread names, pids in order to adjust the thread
> > priorities and SMP affinity.
> > On PREEMPT_RT the NAPI thread is treated (by the user) the same way as
> > the threaded interrupt which means a dedicate CPU affinity for the
> > thread and a higher task priority to be favoured over other tasks on the
> > CPU. Otherwise the NAPI thread can be preempted by other threads
> leading
> > to delays in packet delivery.
> > Having to run ps/ grep is awkward to get the PID right. It is not easy
> > to match the interrupt since there is no obvious relation between the
> > IRQ and the NAPI thread.
> > NAPI threads are enabled often to mitigate the problems caused by a
> > "pending" ksoftirqd (which has been mitigated recently by doing softiqrs
> > regardless of ksoftirqd status). There is still the part that the NAPI
> > thread does not use softnet_data::poll_list.
> 
> This needs to go to the netdev netlink family, not sysfs.
> There's much more information about NAPI to expose and sysfs will
> quickly start showing its limitations.

Based on the discussion in https://lore.kernel.org/netdev/c8476530638a5f4381d64db0e024ed49c2db3b02.camel@gmail.com/T/#m00999652a8b4731fbdb7bf698d2e3666c65a60e7 ,
I am working on a patch series (will post RFCs next week), to extend the
netdev-genl interface to expose napi_ids and associated queues. The patch
series will enable support for retrieving napi information contained in the
netdev struct, such as napi id, queue/queue-set (both RX and TX) associated
with each napi instance etc. I figure this requirement for exposing napi thread
to PID association can be done as a follow-on/extension to my series.