Thread (31 messages) 31 messages, 6 authors, 2025-08-29

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

From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Date: 2025-08-25 21:15:36
Also in: bpf

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/ (local)
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help