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+tcoBZN-k2pM1Dp65SGKMhkJm=7kQY+-97WguR-E=KW3Nhxg@mail.gmail.com>
Date: Tue, 26 Aug 2025 08:06:52 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, 
	pabeni@...hat.com, bjorn@...nel.org, magnus.karlsson@...el.com, 
	jonathan.lemon@...il.com, sdf@...ichev.me, ast@...nel.org, 
	daniel@...earbox.net, hawk@...nel.org, john.fastabend@...il.com, 
	horms@...nel.org, andrew+netdev@...n.ch, bpf@...r.kernel.org, 
	netdev@...r.kernel.org, Jason Xing <kernelxing@...cent.com>
Subject: Re: [PATCH net-next v2 0/9] xsk: improvement performance in copy mode

On Tue, Aug 26, 2025 at 5:15 AM Maciej Fijalkowski
<maciej.fijalkowski@...el.com> wrote:
>
> On Mon, Aug 25, 2025 at 09:53:33PM +0800, Jason Xing wrote:
> > From: Jason Xing <kernelxing@...cent.com>
> >
> > Like in VM using virtio_net, there are not that many machines supporting
> > advanced functions like multi buffer and zerocopy. Using xsk copy mode
> > becomes a default choice.
>
> Are you saying that lack of multi-buffer support in xsk zc virtio_net's
> support stops you from using zc in your setup? or is it something else?

In the VM env, if we want to use those advanced features, we need to
make sure the host provides related flags/features in turn. So it has
nothing to do with the guest kernel. In many big clouds, it's not easy
to upgrade the kernel which means there are many VMs that don't
support multi-buffer.

I will override the commit message with the above description.

>
> >
> > Zerocopy mode has a good feature named multi buffer while copy mode
> > has to transmit skb one by one like normal flows. The latter becomes a
> > half bypass mechanism to some extent compared to thorough bypass plan
> > like DPDK. To avoid much consumption in kernel as much as possible,
> > then bulk/batch xmit plan is proposed. The thought of batch xmit is
> > to aggregate packets in a certain small group like GSO/GRO and then
> > read/allocate/build/send them in different loops.
> >
> > Experiments:
> > 1) Tested on virtio_net on Tencent Cloud.
> > copy mode:     767,743 pps
> > batch mode:  1,055,201 pps (+37.4%)
> > xmit.more:     940,398 pps (+22.4%)
> > Side note:
> > 1) another interesting test is if we test with another thread
> > competing the same queue, a 28% increase (from 405,466 pps to 52,1076 pps)
>
> wrong comma - 521,076

Will correct it.

>
> > can be observed.
> > 2) xmit 'more' item is built on top of batch mode. The number can slightly
> > decrease according to different implementations in host.
> >
> > 2) Tested on i40e at 10Gb/sec.
> > copy mode:   1,109,754 pps
> > batch mode:  2,393,498 pps (+115.6%)
> > xmit.more:   3,024,110 pps (+172.5%)
> > zc mode:    14,879,414 pps
> >
> > [2]: ./xdpsock -i eth1 -t  -S -s 64
>
> Have you tested jumbo frames? Did you run xskxceiver tests?

Not yet, I can test them in the following days.

>
> IMHO this should be sent as RFC. In some further patch you're saying you
> were not sure about some certain thing, so let us discuss it and overall
> approach.
>
> Besides, please work on top of the recent fix that got accepted:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=dd9de524183a1ca0a3c0317a083e8892e0f0eaea

Got it :)

>
> >
> > It's worth mentioning batch process might bring high latency in certain
> > cases like shortage of memroy. So I didn't turn it as the default
>
> memory
>
> > feature for copy mode. The recommended value is 32.
> >
> > ---
> > V2
> > Link: https://lore.kernel.org/all/20250811131236.56206-1-kerneljasonxing@gmail.com/
> > 1. add xmit.more sub-feature (Jesper)
> > 2. add kmem_cache_alloc_bulk (Jesper and Maciej)
> >
> > Jason Xing (9):
> >   xsk: introduce XDP_GENERIC_XMIT_BATCH setsockopt
> >   xsk: add descs parameter in xskq_cons_read_desc_batch()
> >   xsk: introduce locked version of xskq_prod_write_addr_batch
> >   xsk: extend xsk_build_skb() to support passing an already allocated
> >     skb
> >   xsk: add xsk_alloc_batch_skb() to build skbs in batch
> >   xsk: add direct xmit in batch function
> >   xsk: support batch xmit main logic
> >   xsk: support generic batch xmit in copy mode
> >   xsk: support dynamic xmit.more control for batch xmit
> >
> >  Documentation/networking/af_xdp.rst |  11 ++
> >  include/linux/netdevice.h           |   3 +
> >  include/net/xdp_sock.h              |  10 ++
> >  include/uapi/linux/if_xdp.h         |   1 +
> >  net/core/dev.c                      |  21 +++
> >  net/core/skbuff.c                   | 103 ++++++++++++++
> >  net/xdp/xsk.c                       | 200 ++++++++++++++++++++++++++--
> >  net/xdp/xsk_queue.h                 |  29 +++-
> >  tools/include/uapi/linux/if_xdp.h   |   1 +
> >  9 files changed, 360 insertions(+), 19 deletions(-)
> >
> > --
> > 2.41.3
> >

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ