netdev - Re: [PATCH net-next v2] xsk: add indirect call for xsk_destruct

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAL+tcoAm_ScONpFUACi3TcrgKx_DUecZmEXpRJVOMwJHa29K9w@mail.gmail.com>
Date: Fri, 31 Oct 2025 00:43:01 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Alexander Lobakin <aleksander.lobakin@...el.com>, Paolo Abeni <pabeni@...hat.com>, davem@...emloft.net, 
	edumazet@...gle.com, bjorn@...nel.org, magnus.karlsson@...el.com, 
	maciej.fijalkowski@...el.com, jonathan.lemon@...il.com, sdf@...ichev.me, 
	ast@...nel.org, daniel@...earbox.net, hawk@...nel.org, 
	john.fastabend@...il.com, joe@...a.to, willemdebruijn.kernel@...il.com, 
	bpf@...r.kernel.org, netdev@...r.kernel.org, 
	Jason Xing <kernelxing@...cent.com>
Subject: Re: [PATCH net-next v2] xsk: add indirect call for xsk_destruct_skb

On Thu, Oct 30, 2025 at 11:55 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Thu, 30 Oct 2025 11:59:58 +0100 Alexander Lobakin wrote:
> > >> managed to see a huge improvement[1], the same situation can also be
> > >> applied in xsk scenario.
> > >>
> > >> This patch adds an indirect call for xsk and helps current copy mode
> > >> improve the performance by around 1% stably which was observed with
> > >> IXGBE at 10Gb/sec loaded.
> > >
> > > If I follow the conversation correctly, Jakub's concern is mostly about
> > > this change affecting only the copy mode.
> > >
> > > Out of sheer ignorance on my side is not clear how frequent that
> > > scenario is. AFAICS, applications could always do zero-copy with proper
> > > setup, am I correct?!?
> >
> > It is correct only when the target driver implements zero-copy
> > driver-side XSk. While it's true for modern Ethernet drivers for real
> > NICs, "virtual" drivers like virtio-net, veth etc. usually don't have it.
> > It's not as common usecase as using XSk on real NICs, but still valid
> > and widely used.
>
> To be clear my main concern is that the XDP<>skb conversions are
> an endless source of bugs and complexity. We have one fix for XDP->skb
> on the list from Maciej and another for AF_XDP from Fernando which
> tried to create an XDP skb_ext. We are digging a deeper and deeper
> hole with all this fallback stuff, and it will affect performance
> of both normal skb and XDP paths. Optimizing AF_XDP fallback is
> shortsighted.

Sorry, I have to say I'm against the whole point :(

1. Every feature has bugs. Just taking a look at the history of those
well-known features like LRO/GRO/GSO, you must be aware that so many
nasty bugs have been found.
2. The so-called fallback is not something that nobody uses and nobody
cares. It has its right valid position and has actually been used by
many applications. Searching in the github, you can find many related
supports in their own repos. Being generic doesn't mean being
shortsighted and useless. There are a few so-called fallback features
other than this, like SMC-R for RDMA.
3. Back to the main point we've discussed, there are many cases that
don't support zerocopy mode and I don't see anyone who volunteers to
complete the rest of them. So currently and at least in these recent
years I can predict that copy mode can be used widely.
4. I'm working on something that is really beneficial to me and some
people like me who need to accelerate the transmission in copy mode.
There's still a huge gap between zc and copy mode, but sadly we have
no chance to use zc mode. Optimizing the copy mode then becomes my
primary job after work.

I fully understand what you meant here. But the fact is the fact...

As to the maintenance, I believe we're able to cover this area and
make it better and better in every aspect. I really hope we don't get
stuck in these minor optimizations, shall we? I have more copy mode
patches on the way... I really appreciate that we can merge it and
move on. Many thanks here!

Thanks,
Jason