From: Stanislav Fomichev <stfomichev@gmail.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,
maciej.fijalkowski@intel.com, jonathan.lemon@gmail.com,
sdf@fomichev.me, ast@kernel.org, daniel@iogearbox.net,
hawk@kernel.org, john.fastabend@gmail.com, bpf@vger.kernel.org,
netdev@vger.kernel.org, Jason Xing <kernelxing@tencent.com>
Subject: Re: [PATCH net-next v6 2/2] xsk: move cq_cached_prod_lock to avoid touching a cacheline in sending path
Date: Wed, 14 Jan 2026 12:57:15 -0800 [thread overview]
Message-ID: <aWgDK4Zq7NShgql5@mini-arch> (raw)
In-Reply-To: <CAL+tcoDgNWBehTrtYhhdu7qBRkNLNH4FJV5T0an0tmLP+yvtqQ@mail.gmail.com>
On 01/13, Jason Xing wrote:
> On Sun, Jan 4, 2026 at 9:21 AM Jason Xing <kerneljasonxing@gmail.com> wrote:
> >
> > From: Jason Xing <kernelxing@tencent.com>
> >
> > We (Paolo and I) noticed that in the sending path touching an extra
> > cacheline due to cq_cached_prod_lock will impact the performance. After
> > moving the lock from struct xsk_buff_pool to struct xsk_queue, the
> > performance is increased by ~5% which can be observed by xdpsock.
> >
> > An alternative approach [1] can be using atomic_try_cmpxchg() to have the
> > same effect. But unfortunately I don't have evident performance numbers to
> > prove the atomic approach is better than the current patch. The advantage
> > is to save the contention time among multiple xsks sharing the same pool
> > while the disadvantage is losing good maintenance. The full discussion can
> > be found at the following link.
> >
> > [1]: https://lore.kernel.org/all/20251128134601.54678-1-kerneljasonxing@gmail.com/
> >
> > Suggested-by: Paolo Abeni <pabeni@redhat.com>
> > Signed-off-by: Jason Xing <kernelxing@tencent.com>
>
> Hi Magnus, Maciej and Stanislav,
>
> Any feedback on the whole series?
LGTM, thanks! (I'm gonna be a bit slow on the mailing list in Jan/Feb)
next prev parent reply other threads:[~2026-01-14 20:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-04 1:21 [PATCH net-next v6 0/2] xsk: move cq_cached_prod_lock Jason Xing
2026-01-04 1:21 ` [PATCH net-next v6 1/2] xsk: advance cq/fq check when shared umem is used Jason Xing
2026-01-04 1:21 ` [PATCH net-next v6 2/2] xsk: move cq_cached_prod_lock to avoid touching a cacheline in sending path Jason Xing
2026-01-08 8:55 ` Paolo Abeni
2026-01-08 9:07 ` Jason Xing
2026-01-13 5:33 ` Jason Xing
2026-01-14 20:57 ` Stanislav Fomichev [this message]
2026-01-14 20:56 ` [PATCH net-next v6 0/2] xsk: move cq_cached_prod_lock Stanislav Fomichev
2026-01-15 9:20 ` patchwork-bot+netdevbpf
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=aWgDK4Zq7NShgql5@mini-arch \
--to=stfomichev@gmail.com \
--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=john.fastabend@gmail.com \
--cc=jonathan.lemon@gmail.com \
--cc=kerneljasonxing@gmail.com \
--cc=kernelxing@tencent.com \
--cc=kuba@kernel.org \
--cc=maciej.fijalkowski@intel.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.