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: <CAL+tcoDLLqr5q-hvcu0PapnMUwjsewwQjmACG3h3SRWEfSRhYA@mail.gmail.com>
Date: Thu, 30 Oct 2025 18:28:18 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, 
	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>, Alexander Lobakin <aleksander.lobakin@...el.com>
Subject: Re: [PATCH net-next v2] xsk: add indirect call for xsk_destruct_skb

On Thu, Oct 30, 2025 at 6:15 PM Paolo Abeni <pabeni@...hat.com> wrote:
>
> On 10/26/25 3:58 PM, Jason Xing wrote:
> > From: Jason Xing <kernelxing@...cent.com>
> >
> > Since Eric proposed an idea about adding indirect call for UDP and
>
> Minor nit:                          ^^^^^^
>
> either 'remove an indirect call' or 'adding indirect call wrappers'

Oh, right!

>
> > 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.

Copy mode is worth optimization really. Please see below.

>
> 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?!?

In my env, around 2,000,000 packets are sent per second which in turn
means the destruction function gets called the same number of times.

>
> In such case I think this patch is not worth.
>
> Otherwise, please describe/explain the real-use case needing the copy mode.

I gave a detailed explanation in the cover letter [1]. The real use
case from my side is to support the virtio_net and veth scenario. This
topic has been discussed in the version 1 of [1] and Jesper also
acknowledged this point. I also noticed that there remain some
physical nics that haven't supported zerocopy mode yet and some of
them[2] are still in progress.

[1]: https://lore.kernel.org/all/20251021131209.41491-1-kerneljasonxing@gmail.com/
[2]: https://lore.kernel.org/all/20251014105613.2808674-1-m-malladi@ti.com/

Thanks,
Jason

>
> Thanks,
>
> Paolo
>