[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aApYUEjA3Jcklazg@boxer>
Date: Thu, 24 Apr 2025 17:27:12 +0200
From: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
To: Alexander Lobakin <aleksander.lobakin@...el.com>
CC: <intel-wired-lan@...ts.osuosl.org>, Michal Kubiak
<michal.kubiak@...el.com>, Tony Nguyen <anthony.l.nguyen@...el.com>, "Przemek
Kitszel" <przemyslaw.kitszel@...el.com>, Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, "Alexei
Starovoitov" <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
"Jesper Dangaard Brouer" <hawk@...nel.org>, John Fastabend
<john.fastabend@...il.com>, Simon Horman <horms@...nel.org>,
<bpf@...r.kernel.org>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH iwl-next 06/16] libeth: xdp: add XDPSQ locking helpers
On Tue, Apr 15, 2025 at 07:28:15PM +0200, Alexander Lobakin wrote:
> Unfortunately, it's not always possible to allocate
> max(num_rxqs, nr_cpu_ids) even on hi-end NICs.
> To mitigate this, add simple locking helpers to libeth_xdp.
> As long as XDPSQs are not shared, the whole functionality is gated
> behind a static lock. Otherwise, each bulk flush locks the queue for
> the time of cleaning and filling the descriptors.
> As long as this particular queue is not used by more than 1 CPU,
> the impact is minimal (runtime check for boolean twice per 16+
> descriptors).
>
> Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@...el.com> # static key
> Signed-off-by: Alexander Lobakin <aleksander.lobakin@...el.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
Powered by blists - more mailing lists