> -----Original Message-----
> From: Intel-wired-lan <[email protected]> On Behalf Of
> Alexander Lobakin
> Sent: Tuesday, August 26, 2025 9:25 PM
> To: [email protected]
> Cc: Lobakin, Aleksander <[email protected]>; Kubiak, Michal
> <[email protected]>; Fijalkowski, Maciej
> <[email protected]>; Nguyen, Anthony L
> <[email protected]>; Kitszel, Przemyslaw
> <[email protected]>; Andrew Lunn <[email protected]>;
> David S. Miller <[email protected]>; Eric Dumazet
> <[email protected]>; Jakub Kicinski <[email protected]>; Paolo Abeni
> <[email protected]>; Alexei Starovoitov <[email protected]>; Daniel
> Borkmann <[email protected]>; Simon Horman <[email protected]>;
> NXNE CNSE OSDT ITP Upstreaming
> <[email protected]>; [email protected];
> [email protected]; [email protected]
> 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 <[email protected]> # helper
> Signed-off-by: Alexander Lobakin <[email protected]>
> ---
> 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 <[email protected]>
