netdev - Re: [PATCH net-next] xsk: skip validating skb list in xmit path

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+tcoAn8ADUGARSzZB=5dGoa+Kh7HnNBLxyqTa3W6tOhUK-sg@mail.gmail.com>
Date: Wed, 16 Jul 2025 07:39:08 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Stanislav Fomichev <stfomichev@...il.com>, davem@...emloft.net, edumazet@...gle.com, 
	pabeni@...hat.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] xsk: skip validating skb list in xmit path

On Wed, Jul 16, 2025 at 7:19 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Tue, 15 Jul 2025 07:53:19 +0800 Jason Xing wrote:
> > > Although, again, if you care about performance, why not use zerocopy
> > > mode?
> >
> > I attached the performance impact because I'm working on the different
> > modes in xsk to see how it really behaves. You can take it as a kind
> > of investigation :)
>
> How does the copy mode compare to a normal packet socket?

We combine a TCP user-space stack that is not mature obviously with
this copy mode af_xdp in the virtual machine, seeing that in some
cases:
1) in the real workload the cpu% could be minimized a lot (almost
50%), which is one of factors we care about most of the time.
2) the throughput does not always outperform TCP in the kernel. So
far, only in request & response cases, we're able to see xsk ramp up
the transmission.

I'm focusing on the physical machine scenario in the meantime.
Everything went not well admittedly.

As I said, I'm still trying to find/test every possible feature in
xsk, hoping to find a final solution to deploy.

I'm also thinking if it's possible to 1) remove the sendto syscall
that is used to drive/notify the xsk, 2) prepare enough skbs
beforehand instead of allocating one and then freeing it over and over
again. Well, these so-called ideas are just out of thin air :p

Thanks,
Jason