Re: [PATCH net-next v2 0/9] xsk: improvement performance in copy mode

[Maciej Fijalkowski <maciej.fijalkowski@intel.com>]

On Mon, Aug 25, 2025 at 09:53:33PM +0800, Jason Xing wrote:
> From: Jason Xing <kernelxing@tencent.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?

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

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

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

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