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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251030085535.4f658dd8@kernel.org>
Date: Thu, 30 Oct 2025 08:55:35 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Alexander Lobakin <aleksander.lobakin@...el.com>
Cc: Paolo Abeni <pabeni@...hat.com>, Jason Xing <kerneljasonxing@...il.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, 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.