RE: [Intel-wired-lan] [PATCH iwl-next v5 04/13] idpf: link NAPIs to queues

-----Original Message-----
From: Intel-wired-lan <redacted> On Behalf Of
Alexander Lobakin
Sent: Tuesday, August 26, 2025 9:25 PM
To: intel-wired-lan@lists.osuosl.org
Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Kubiak, Michal
[off-list ref]; Fijalkowski, Maciej
[off-list ref]; Nguyen, Anthony L
[off-list ref]; Kitszel, Przemyslaw
[off-list ref]; Andrew Lunn [off-list ref];
David S. Miller [off-list ref]; Eric Dumazet
[off-list ref]; Jakub Kicinski [off-list ref]; Paolo Abeni
[off-list ref]; Alexei Starovoitov [off-list ref]; Daniel
Borkmann [off-list ref]; Simon Horman [off-list ref];
NXNE CNSE OSDT ITP Upstreaming
[off-list ref]; bpf@vger.kernel.org;
netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: [Intel-wired-lan] [PATCH iwl-next v5 04/13] idpf: link NAPIs to queues

Add the missing linking of NAPIs to netdev queues when enabling interrupt
vectors in order to support NAPI configuration and interfaces requiring
get_rx_queue()->napi to be set (like XSk busy polling).

As currently, idpf_vport_{start,stop}() is called from several flows with
inconsistent RTNL locking, we need to synchronize them to avoid runtime
assertions. Notably:

* idpf_{open,stop}() -- regular NDOs, RTNL is always taken;
* idpf_initiate_soft_reset() -- usually called under RTNL;
* idpf_init_task -- called from the init work, needs RTNL;
* idpf_vport_dealloc -- called without RTNL taken, needs it.

Expand common idpf_vport_{start,stop}() to take an additional bool telling
whether we need to manually take the RTNL lock.

Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> # helper
Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
---
 drivers/net/ethernet/intel/idpf/idpf_lib.c  | 38 +++++++++++++++------
drivers/net/ethernet/intel/idpf/idpf_txrx.c | 17 +++++++++
 2 files changed, 45 insertions(+), 10 deletions(-)

Tested-by: R,Ramu <redacted>