From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Jason Xing <kerneljasonxing@gmail.com>
Cc: <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
<pabeni@redhat.com>, <bjorn@kernel.org>,
<magnus.karlsson@intel.com>, <jonathan.lemon@gmail.com>,
<sdf@fomichev.me>, <ast@kernel.org>, <daniel@iogearbox.net>,
<hawk@kernel.org>, <john.fastabend@gmail.com>, <horms@kernel.org>,
<andrew+netdev@lunn.ch>, <bpf@vger.kernel.org>,
<netdev@vger.kernel.org>, Jason Xing <kernelxing@tencent.com>
Subject: Re: [PATCH net-next 1/2] xsk: avoid using heavy lock when the pool is not shared
Date: Wed, 29 Oct 2025 16:48:29 +0100 [thread overview]
Message-ID: <aQI3TfFZPPaWQOS/@boxer> (raw)
In-Reply-To: <20251025065310.5676-2-kerneljasonxing@gmail.com>
On Sat, Oct 25, 2025 at 02:53:09PM +0800, Jason Xing wrote:
> From: Jason Xing <kernelxing@tencent.com>
>
> The commit f09ced4053bc ("xsk: Fix race in SKB mode transmit with
> shared cq") uses a heavy lock (spin_lock_irqsave) for the shared
> pool scenario which is that multiple sockets share the same pool.
>
> It does harm to the case where the pool is only owned by one xsk.
> The patch distinguishes those two cases through checking if the xsk
> list only has one xsk. If so, that means the pool is exclusive and
> we don't need to hold the lock and disable IRQ at all. The benefit
> of this is to avoid those two operations being executed extremely
> frequently.
Even with a single CQ producer we need to have related code within
critical section. One core can be in process context via sendmsg() and
for some reason xmit failed and driver consumed skb (destructor called).
Other core can be at same time calling the destructor on different skb
that has been successfully xmitted, doing the Tx completion via driver's
NAPI. This means that without locking the SPSC concept would be violated.
So I'm afraid I have to nack this.
>
> With this patch, the performance number[1] could go from 1,872,565 pps
> to 2,147,803 pps. It's a noticeable rise of around 14.6%.
>
> [1]: taskset -c 1 ./xdpsock -i enp2s0f1 -q 0 -t -S -s 64
>
> Signed-off-by: Jason Xing <kernelxing@tencent.com>
> ---
> net/xdp/xsk.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 7b0c68a70888..76f797fcc49c 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -548,12 +548,15 @@ static int xsk_wakeup(struct xdp_sock *xs, u8 flags)
>
> static int xsk_cq_reserve_locked(struct xsk_buff_pool *pool)
> {
> + bool lock = !list_is_singular(&pool->xsk_tx_list);
> unsigned long flags;
> int ret;
>
> - spin_lock_irqsave(&pool->cq_lock, flags);
> + if (lock)
> + spin_lock_irqsave(&pool->cq_lock, flags);
> ret = xskq_prod_reserve(pool->cq);
> - spin_unlock_irqrestore(&pool->cq_lock, flags);
> + if (lock)
> + spin_unlock_irqrestore(&pool->cq_lock, flags);
>
> return ret;
> }
> @@ -588,11 +591,14 @@ static void xsk_cq_submit_addr_locked(struct xsk_buff_pool *pool,
>
> static void xsk_cq_cancel_locked(struct xsk_buff_pool *pool, u32 n)
> {
> + bool lock = !list_is_singular(&pool->xsk_tx_list);
> unsigned long flags;
>
> - spin_lock_irqsave(&pool->cq_lock, flags);
> + if (lock)
> + spin_lock_irqsave(&pool->cq_lock, flags);
> xskq_prod_cancel_n(pool->cq, n);
> - spin_unlock_irqrestore(&pool->cq_lock, flags);
> + if (lock)
> + spin_unlock_irqrestore(&pool->cq_lock, flags);
> }
>
> static void xsk_inc_num_desc(struct sk_buff *skb)
> --
> 2.41.3
>
next prev parent reply other threads:[~2025-10-29 15:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-25 6:53 [PATCH net-next 0/2] xsk: mitigate the side effect of cq_lock Jason Xing
2025-10-25 6:53 ` [PATCH net-next 1/2] xsk: avoid using heavy lock when the pool is not shared Jason Xing
2025-10-29 0:29 ` Jakub Kicinski
2025-10-29 1:36 ` Jason Xing
2025-10-29 15:48 ` Maciej Fijalkowski [this message]
2025-10-29 23:43 ` Jason Xing
2025-10-25 6:53 ` [PATCH net-next 2/2] xsk: use a smaller new lock for shared pool case Jason Xing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aQI3TfFZPPaWQOS/@boxer \
--to=maciej.fijalkowski@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jonathan.lemon@gmail.com \
--cc=kerneljasonxing@gmail.com \
--cc=kernelxing@tencent.com \
--cc=kuba@kernel.org \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).