From: Jason Xing <hidden> Date: 2025-08-25 13:54:09
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.
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)
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
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
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
From: Jason Xing <hidden> Date: 2025-08-25 13:54:13
From: Jason Xing <kernelxing@tencent.com>
Add a new socket option to provide an alternative to achieve a higher
overall throughput with the rest of series applied.
Init skb_cache and desc_batch when setting setsockopt with xs->mutex
protection.
skb_cache will be used to store newly allocated skb at one time in the
xmit path. desc_batch will be used to temporarily store descriptors of
pool.
Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
Documentation/networking/af_xdp.rst | 11 +++++++
include/net/xdp_sock.h | 3 ++
include/uapi/linux/if_xdp.h | 1 +
net/xdp/xsk.c | 47 +++++++++++++++++++++++++++++
tools/include/uapi/linux/if_xdp.h | 1 +
5 files changed, 63 insertions(+)
@@ -447,6 +447,17 @@ mode to allow application to tune the per-socket maximum iteration for better throughput and less frequency of send syscall. Allowed range is [32, xs->tx->nentries].+XDP_GENERIC_XMIT_BATCH+----------------------++It provides an option that allows application to use batch xmit in the copy+mode. Batch process tries to allocate a certain number skbs through bulk+mechanism first and then send them out at one time, minimizing the number+of grabbing/releasing a few locks (like cache lock and queue lock).+it normally gains the overall performance improvement as observed by+xdpsock benchmark, whereas it might increase the latency of per packet.+The maximum value shouldn't be larger than xs->max_tx_budget.+ XDP_STATISTICS getsockopt -------------------------
@@ -89,6 +90,8 @@ struct xdp_sock {structmutexmutex;structxsk_queue*fq_tmp;/* Only as tmp storage before bind */structxsk_queue*cq_tmp;/* Only as tmp storage before bind */+structsk_buff**skb_cache;+structxdp_desc*desc_batch;};/*
@@ -1122,6 +1122,8 @@ static int xsk_release(struct socket *sock)xskq_destroy(xs->tx);xskq_destroy(xs->fq_tmp);xskq_destroy(xs->cq_tmp);+kfree(xs->skb_cache);+kvfree(xs->desc_batch);sock_orphan(sk);sock->sk=NULL;
@@ -1456,6 +1458,51 @@ static int xsk_setsockopt(struct socket *sock, int level, int optname,WRITE_ONCE(xs->max_tx_budget,budget);return0;}+caseXDP_GENERIC_XMIT_BATCH:+{+structxdp_desc*descs;+structsk_buff**skbs;+unsignedintbatch;+intret=0;++if(optlen!=sizeof(batch))+return-EINVAL;+if(copy_from_sockptr(&batch,optval,sizeof(batch)))+return-EFAULT;+if(batch>xs->max_tx_budget)+return-EACCES;++mutex_lock(&xs->mutex);+if(!batch){+kfree(xs->skb_cache);+kvfree(xs->desc_batch);+xs->generic_xmit_batch=0;+gotoout;+}++skbs=kmalloc(batch*sizeof(structsk_buff*),GFP_KERNEL);+if(!skbs){+ret=-ENOMEM;+gotoout;+}+descs=kvcalloc(batch,sizeof(*xs->desc_batch),GFP_KERNEL);+if(!skbs){+kfree(skbs);+ret=-ENOMEM;+gotoout;+}+if(xs->skb_cache)+kfree(xs->skb_cache);+if(xs->desc_batch)+kvfree(xs->desc_batch);++xs->skb_cache=skbs;+xs->desc_batch=descs;+xs->generic_xmit_batch=batch;+out:+mutex_unlock(&xs->mutex);+returnret;+}default:break;}
From: Jason Xing <hidden> Date: 2025-08-25 13:54:17
From: Jason Xing <kernelxing@tencent.com>
Add a new parameter to let generic xmit call this interface in the
subsequent patches.
Prior to this patch, pool->tx_descs in xskq_cons_read_desc_batch() is
only used to store a small number of descs in zerocopy mode. Later
another similar cache named xs->desc_batch will be used in copy mode.
So adjust the parameter for copy mode.
Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
net/xdp/xsk.c | 2 +-
net/xdp/xsk_queue.h | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
From: Jason Xing <hidden> Date: 2025-08-25 13:54:22
From: Jason Xing <kernelxing@tencent.com>
Add xskq_prod_write_addr_batch_locked() helper for batch xmit.
xskq_prod_write_addr_batch() is used in the napi poll env which is
already in the softirq so it doesn't need any lock protection. Later
this function will be used in the generic xmit path that is non irq,
so the locked version as this patch adds is needed.
Also add nb_pkts in xskq_prod_write_addr_batch() to count how many
skbs instead of descs will be used in the batch xmit at one time, so
that main batch xmit function can decide how many skbs will be
allocated. Note that xskq_prod_write_addr_batch() was designed to
help zerocopy mode because it only cares about descriptors/data itself.
Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
net/xdp/xsk_queue.h | 26 +++++++++++++++++++++++---
1 file changed, 23 insertions(+), 3 deletions(-)
From: Jason Xing <hidden> Date: 2025-08-25 13:54:26
From: Jason Xing <kernelxing@tencent.com>
Batch xmit mode needs to allocate and build skbs at one time. To avoid
reinvent the wheel, use xsk_build_skb() as the second half process of
the whole initialization of each skb.
The original xsk_build_skb() itself allocates a new skb by calling
sock_alloc_send_skb whether in copy mode or zerocopy mode. Add a new
parameter allocated skb to let other callers to pass an already
allocated skb to support later xmit batch feature. At that time,
another building skb function will generate a new skb and pass it to
xsk_build_skb() to finish the rest of building process, like
initializing structures and copying data.
Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
include/net/xdp_sock.h | 4 ++++
net/xdp/xsk.c | 23 ++++++++++++++++-------
2 files changed, 20 insertions(+), 7 deletions(-)
From: Jason Xing <hidden> Date: 2025-08-25 13:54:31
From: Jason Xing <kernelxing@tencent.com>
Support allocating and building skbs in batch.
This patch uses kmem_cache_alloc_bulk() to complete the batch allocation
which relies on the global common cache 'net_hotdata.skbuff_cache'. Use
a xsk standalone skb cache (namely, xs->skb_cache) to store skbs instead
of resorting to napi_alloc_cache that was designed for softirq condition.
In case that memory shortage occurs, to avoid frequently allocating
skbs and then freeing part of them, using the allocated skbs from cache
in a reversed order (like from 10, 9, ..., 2, 1, 0) solves the issue.
After allocating memory for each of skbs, in a 'for' loop, the patch
borrows part of __allocate_skb() to initializing skb and then calls
xsk_build_skb() to complete the rest of whole process, like copying data
and stuff.
Considering passing no fclone flag during allocation period, in terms of
freeing process, napi_consume_skb() in the tx completion would put the
skb into different and global cache 'net_hotdata.skbuff_cache' that
implements the deferred freeing skb feature to avoid freeing skb one
by one.
Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
include/net/xdp_sock.h | 3 ++
net/core/skbuff.c | 103 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 106 insertions(+)
@@ -92,6 +92,7 @@ struct xdp_sock {structxsk_queue*cq_tmp;/* Only as tmp storage before bind */structsk_buff**skb_cache;structxdp_desc*desc_batch;+unsignedintskb_count;};/*
@@ -614,6 +616,107 @@ static void *kmalloc_reserve(unsigned int *size, gfp_t flags, int node,returnobj;}+intxsk_alloc_batch_skb(structxdp_sock*xs,u32nb_pkts,u32nb_descs,+int*consumed,int*start,int*end)+{+structxdp_desc*descs=xs->desc_batch;+structsk_buff**skbs=xs->skb_cache;+gfp_tgfp_mask=xs->sk.sk_allocation;+structnet_device*dev=xs->dev;+intnode=NUMA_NO_NODE;+structsk_buff*skb;+u32i=0,j=0;+boolpfmemalloc;+u32base_len;+interr=0;+u8*data;++base_len=max(NET_SKB_PAD,L1_CACHE_ALIGN(dev->needed_headroom));+if(!(dev->priv_flags&IFF_TX_SKB_NO_LINEAR))+base_len+=dev->needed_tailroom;++if(xs->skb_count>=nb_pkts)+gotobuild;++if(xs->skb){+i=1;+xs->skb_count++;+}++xs->skb_count+=kmem_cache_alloc_bulk(net_hotdata.skbuff_cache,+gfp_mask,nb_pkts-xs->skb_count,+(void**)&skbs[xs->skb_count]);+if(xs->skb_count<nb_pkts)+nb_pkts=xs->skb_count;++build:+for(i=0,j=0;j<nb_descs;j++){+if(!xs->skb){+u32size=base_len+descs[j].len;++/* In case we don't have enough allocated skbs */+if(i>=nb_pkts){+err=-EAGAIN;+break;+}++if(sk_wmem_alloc_get(&xs->sk)>READ_ONCE(xs->sk.sk_sndbuf)){+err=-EAGAIN;+break;+}++skb=skbs[xs->skb_count-1-i];++prefetchw(skb);+/* We do our best to align skb_shared_info on a separate cache+*line.Itusuallyworksbecausekmalloc(X>SMP_CACHE_BYTES)gives+*alignedmemoryblocks,unlessSLUB/SLABdebugisenabled.+*Bothskb->headandskb_shared_infoarecachelinealigned.+*/+data=kmalloc_reserve(&size,gfp_mask,node,&pfmemalloc);+if(unlikely(!data)){+err=-ENOBUFS;+break;+}+/* kmalloc_size_roundup() might give us more room than requested.+*Putskb_shared_infoexactlyattheendofallocatedzone,+*toallowmaxpossiblefillingbeforereallocation.+*/+prefetchw(data+SKB_WITH_OVERHEAD(size));++memset(skb,0,offsetof(structsk_buff,tail));+__build_skb_around(skb,data,size);+skb->pfmemalloc=pfmemalloc;+skb_set_owner_w(skb,&xs->sk);+}elseif(unlikely(i==0)){+/* We have a skb in cache that is left last time */+kmem_cache_free(net_hotdata.skbuff_cache,skbs[xs->skb_count-1]);+skbs[xs->skb_count-1]=xs->skb;+}++skb=xsk_build_skb(xs,skb,&descs[j]);+if(IS_ERR(skb)){+err=PTR_ERR(skb);+break;+}++if(xp_mb_desc(&descs[j])){+xs->skb=skb;+continue;+}++xs->skb=NULL;+i++;+}++*consumed=j;+*start=xs->skb_count-1;+*end=xs->skb_count-i;+xs->skb_count-=i;++returnerr;+}+/* Allocate a new skbuff. We do this ourselves so we can fill in a few*'private'fieldsandalsodomemorystatisticstofindallthe*[BEEP]leaks.
From: Jason Xing <hidden> Date: 2025-08-25 13:54:35
From: Jason Xing <kernelxing@tencent.com>
Add batch xmit logic.
Only grabbing the lock and disable bottom half once and sent all
the aggregated packets in one loop.
Since previous patch puts descriptors in xs->skb_cache in a reversed
order, this patch sends each skb out from start to end when 'start' is
not smaller than 'end'.
Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
include/linux/netdevice.h | 3 +++
net/core/dev.c | 19 +++++++++++++++++++
2 files changed, 22 insertions(+)
From: Jason Xing <hidden> Date: 2025-08-25 13:54:40
From: Jason Xing <kernelxing@tencent.com>
This function __xsk_generic_xmit_batch() is the core function in batches
xmit, implement a batch version of __xsk_generic_xmit().
The whole logic is divided into sections:
1. check if we have enough available slots in tx ring and completion
ring.
2. read descriptors from tx ring into xs->desc_batch in batches
3. reserve enough slots in completion ring to avoid backpressure
4. allocate and build skbs in batches
5. send all the possible packets in batches at one time
Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
net/xdp/xsk.c | 117 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 117 insertions(+)
@@ -789,6 +789,123 @@ struct sk_buff *xsk_build_skb(struct xdp_sock *xs,returnERR_PTR(err);}+staticint__xsk_generic_xmit_batch(structxdp_sock*xs)+{+structxdp_desc*descs=xs->desc_batch;+structxsk_buff_pool*pool=xs->pool;+structsk_buff**skbs=xs->skb_cache;+u32nb_pkts,nb_descs,cons_descs;+structnet_device*dev=xs->dev;+intstart=0,end=0,cur=-1;+u32i=0,max_budget;+structnetdev_queue*txq;+boolsent_frame=false;+u32max_batch,expected;+interr=0;++mutex_lock(&xs->mutex);++/* Since we dropped the RCU read lock, the socket state might have changed. */+if(unlikely(!xsk_is_bound(xs))){+err=-ENXIO;+gotoout;+}++if(xs->queue_id>=dev->real_num_tx_queues)+gotoout;++if(unlikely(!netif_running(dev)||+!netif_carrier_ok(dev)))+gotoout;++max_budget=READ_ONCE(xs->max_tx_budget);+max_batch=xs->generic_xmit_batch;+txq=netdev_get_tx_queue(dev,xs->queue_id);++for(i=0;i<max_budget;i+=cons_descs){+expected=max_budget-i;+expected=max_batch>expected?expected:max_batch;+nb_descs=xskq_cons_nb_entries(xs->tx,expected);+if(!nb_descs)+gotoout;++/* This is the backpressure mechanism for the Tx path. Try to+*reservespaceinthecompletionqueueforallpackets,but+*iftherearefewerslotsavailable,justprocessthatmany+*packets.Thisavoidshavingtoimplementanybufferingin+*theTxpath.+*/+nb_descs=xskq_prod_nb_free(pool->cq,nb_descs);+if(!nb_descs){+err=-EAGAIN;+gotoout;+}++nb_descs=xskq_cons_read_desc_batch(xs->tx,pool,descs,nb_descs);+if(!nb_descs){+err=-EAGAIN;+xs->tx->queue_empty_descs++;+gotoout;+}++nb_pkts=xskq_prod_write_addr_batch_locked(pool,descs,nb_descs);++err=xsk_alloc_batch_skb(xs,nb_pkts,nb_descs,&cons_descs,&start,&end);+/* Return 'nb_descs - cons_descs' number of descs to the+*poolifthebatchallocationpartiallyfails+*/+if(cons_descs<nb_descs){+xskq_cons_cancel_n(xs->tx,nb_descs-cons_descs);+xsk_cq_cancel_locked(xs->pool,nb_descs-cons_descs);+}++if(start>=end){+interr_xmit;++err_xmit=xsk_direct_xmit_batch(skbs,dev,txq,+&cur,start,end);+if(err_xmit==NETDEV_TX_BUSY){+err=-EAGAIN;+}elseif(err_xmit==NET_XMIT_DROP){+cur++;+err=-EBUSY;+}++sent_frame=true;+xs->skb=NULL;+}++if(err)+gotoout;++start=0;+end=0;+cur=-1;+}++/* Maximum budget of descriptors have been consumed */+err=-EAGAIN;++if(xskq_has_descs(xs->tx)){+if(xs->skb)+xsk_drop_skb(xs->skb);+}++out:+/* If cur is larger than end, we must to clear the rest of+*sbksstayingintheskb_cache+*/+for(;cur>=end;cur--){+xskq_cons_cancel_n(xs->tx,xsk_get_num_desc(skbs[cur]));+xsk_consume_skb(skbs[cur]);+}+if(sent_frame)+__xsk_tx_release(xs);++mutex_unlock(&xs->mutex);+returnerr;+}+staticint__xsk_generic_xmit(structsock*sk){structxdp_sock*xs=xdp_sk(sk);
@@ -803,8 +803,6 @@ static int __xsk_generic_xmit_batch(struct xdp_sock *xs)u32max_batch,expected;interr=0;-mutex_lock(&xs->mutex);-/* Since we dropped the RCU read lock, the socket state might have changed. */if(unlikely(!xsk_is_bound(xs))){err=-ENXIO;
@@ -902,21 +900,17 @@ static int __xsk_generic_xmit_batch(struct xdp_sock *xs)if(sent_frame)__xsk_tx_release(xs);-mutex_unlock(&xs->mutex);returnerr;}-staticint__xsk_generic_xmit(structsock*sk)+staticint__xsk_generic_xmit(structxdp_sock*xs){-structxdp_sock*xs=xdp_sk(sk);boolsent_frame=false;structxdp_descdesc;structsk_buff*skb;u32max_batch;interr=0;-mutex_lock(&xs->mutex);-/* Since we dropped the RCU read lock, the socket state might have changed. */if(unlikely(!xsk_is_bound(xs))){err=-ENXIO;
@@ -991,17 +985,22 @@ static int __xsk_generic_xmit(struct sock *sk)if(sent_frame)__xsk_tx_release(xs);-mutex_unlock(&xs->mutex);returnerr;}staticintxsk_generic_xmit(structsock*sk){+structxdp_sock*xs=xdp_sk(sk);intret;/* Drop the RCU lock since the SKB path might sleep. */rcu_read_unlock();-ret=__xsk_generic_xmit(sk);+mutex_lock(&xs->mutex);+if(xs->generic_xmit_batch)+ret=__xsk_generic_xmit_batch(xs);+else+ret=__xsk_generic_xmit(xs);+mutex_unlock(&xs->mutex);/* Reaquire RCU lock before going into common code. */rcu_read_lock();
From: Jason Xing <hidden> Date: 2025-08-25 13:54:49
From: Jason Xing <kernelxing@tencent.com>
Only set xmit.more false for the last skb.
In theory, only making xmit.more false for the last packets to be
sent in each round can bring much benefit like avoid triggering too
many irqs.
Compared to the numbers for batch mode, a huge improvement (26%) can
be seen on i40e driver while a slight decrease (10%) on virtio_net.
Suggested-by: Jesper Dangaard Brouer <hawk@kernel.org>
Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
Considering different implmentation in VM and host, I'm not sure if
we need to create another setsockopt to control this...
---
net/core/dev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Stanislav Fomichev <hidden> Date: 2025-08-25 17:34:57
On 08/25, Jason Xing wrote:
quoted hunk
From: Jason Xing <kernelxing@tencent.com>
Add batch xmit logic.
Only grabbing the lock and disable bottom half once and sent all
the aggregated packets in one loop.
Since previous patch puts descriptors in xs->skb_cache in a reversed
order, this patch sends each skb out from start to end when 'start' is
not smaller than 'end'.
Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
include/linux/netdevice.h | 3 +++
net/core/dev.c | 19 +++++++++++++++++++
2 files changed, 22 insertions(+)
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Date: 2025-08-25 21:15:36
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
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Date: 2025-08-25 21:19:04
On Mon, Aug 25, 2025 at 09:53:35PM +0800, Jason Xing wrote:
From: Jason Xing <kernelxing@tencent.com>
Add a new parameter to let generic xmit call this interface in the
subsequent patches.
Prior to this patch, pool->tx_descs in xskq_cons_read_desc_batch() is
only used to store a small number of descs in zerocopy mode. Later
another similar cache named xs->desc_batch will be used in copy mode.
So adjust the parameter for copy mode.
Explain why you couldn't reuse tx_descs as-is. Pool can not work both in
copy and zero-copy modes at the same time so I don't see the reason why
you couldn't reuse this for your needs?
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Date: 2025-08-25 21:43:13
On Mon, Aug 25, 2025 at 09:53:36PM +0800, Jason Xing wrote:
From: Jason Xing <kernelxing@tencent.com>
Add xskq_prod_write_addr_batch_locked() helper for batch xmit.
xskq_prod_write_addr_batch() is used in the napi poll env which is
already in the softirq so it doesn't need any lock protection. Later
this function will be used in the generic xmit path that is non irq,
so the locked version as this patch adds is needed.
Also add nb_pkts in xskq_prod_write_addr_batch() to count how many
skbs instead of descs will be used in the batch xmit at one time, so
that main batch xmit function can decide how many skbs will be
allocated. Note that xskq_prod_write_addr_batch() was designed to
help zerocopy mode because it only cares about descriptors/data itself.
I am not sure if this patch is valid after patch I cited in response to
your cover letter. in copy mode, skb destructor is responsible now for
producing cq entries.
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Date: 2025-08-25 21:49:19
On Mon, Aug 25, 2025 at 09:53:37PM +0800, Jason Xing wrote:
From: Jason Xing <kernelxing@tencent.com>
Batch xmit mode needs to allocate and build skbs at one time. To avoid
reinvent the wheel, use xsk_build_skb() as the second half process of
the whole initialization of each skb.
The original xsk_build_skb() itself allocates a new skb by calling
sock_alloc_send_skb whether in copy mode or zerocopy mode. Add a new
parameter allocated skb to let other callers to pass an already
allocated skb to support later xmit batch feature. At that time,
another building skb function will generate a new skb and pass it to
xsk_build_skb() to finish the rest of building process, like
initializing structures and copying data.
are you saying you were able to avoid sock_alloc_send_skb() calls for
batching approach and your socket memory accounting problems disappeared?
I've asked you multiple times to add comparison with the performance
of AF_PACKET. What's the disconnect?
Sorry for missing the question. I'm not very familiar with how to run the
test based on AF_PACKET. Could you point it out for me? Thanks.
I remember the very initial version of AF_XDP was pure AF_PACKET. So
may I ask why we expect to see the comparison between them?
Thanks,
Jason
From: Jason Xing <hidden> Date: 2025-08-26 00:07:29
On Tue, Aug 26, 2025 at 5:15 AM Maciej Fijalkowski
[off-list ref] wrote:
On Mon, Aug 25, 2025 at 09:53:33PM +0800, Jason Xing wrote:
quoted
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?
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.
quoted
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.
quoted
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?
From: Jason Xing <hidden> Date: 2025-08-26 00:11:25
On Tue, Aug 26, 2025 at 5:19 AM Maciej Fijalkowski
[off-list ref] wrote:
On Mon, Aug 25, 2025 at 09:53:35PM +0800, Jason Xing wrote:
quoted
From: Jason Xing <kernelxing@tencent.com>
Add a new parameter to let generic xmit call this interface in the
subsequent patches.
Prior to this patch, pool->tx_descs in xskq_cons_read_desc_batch() is
only used to store a small number of descs in zerocopy mode. Later
another similar cache named xs->desc_batch will be used in copy mode.
So adjust the parameter for copy mode.
Explain why you couldn't reuse tx_descs as-is. Pool can not work both in
copy and zero-copy modes at the same time so I don't see the reason why
you couldn't reuse this for your needs?
Oh, right, spot on. I can reuse them instead of creating similar
wheels. Let me try this way.
Thanks,
Jason
From: Jason Xing <hidden> Date: 2025-08-26 00:13:48
On Tue, Aug 26, 2025 at 5:43 AM Maciej Fijalkowski
[off-list ref] wrote:
On Mon, Aug 25, 2025 at 09:53:36PM +0800, Jason Xing wrote:
quoted
From: Jason Xing <kernelxing@tencent.com>
Add xskq_prod_write_addr_batch_locked() helper for batch xmit.
xskq_prod_write_addr_batch() is used in the napi poll env which is
already in the softirq so it doesn't need any lock protection. Later
this function will be used in the generic xmit path that is non irq,
so the locked version as this patch adds is needed.
Also add nb_pkts in xskq_prod_write_addr_batch() to count how many
skbs instead of descs will be used in the batch xmit at one time, so
that main batch xmit function can decide how many skbs will be
allocated. Note that xskq_prod_write_addr_batch() was designed to
help zerocopy mode because it only cares about descriptors/data itself.
I am not sure if this patch is valid after patch I cited in response to
your cover letter. in copy mode, skb destructor is responsible now for
producing cq entries.
Please give me more time to think about it. Seems that I have to change a lot.
Thanks,
Jason
From: Jason Xing <hidden> Date: 2025-08-26 00:27:18
On Tue, Aug 26, 2025 at 5:49 AM Maciej Fijalkowski
[off-list ref] wrote:
On Mon, Aug 25, 2025 at 09:53:37PM +0800, Jason Xing wrote:
quoted
From: Jason Xing <kernelxing@tencent.com>
Batch xmit mode needs to allocate and build skbs at one time. To avoid
reinvent the wheel, use xsk_build_skb() as the second half process of
the whole initialization of each skb.
The original xsk_build_skb() itself allocates a new skb by calling
sock_alloc_send_skb whether in copy mode or zerocopy mode. Add a new
parameter allocated skb to let other callers to pass an already
allocated skb to support later xmit batch feature. At that time,
another building skb function will generate a new skb and pass it to
xsk_build_skb() to finish the rest of building process, like
initializing structures and copying data.
are you saying you were able to avoid sock_alloc_send_skb() calls for
batching approach and your socket memory accounting problems disappeared?
From: Jason Xing <hidden> Date: 2025-08-26 00:28:06
On Tue, Aug 26, 2025 at 1:34 AM Stanislav Fomichev [off-list ref] wrote:
On 08/25, Jason Xing wrote:
quoted
From: Jason Xing <kernelxing@tencent.com>
Add batch xmit logic.
Only grabbing the lock and disable bottom half once and sent all
the aggregated packets in one loop.
Since previous patch puts descriptors in xs->skb_cache in a reversed
order, this patch sends each skb out from start to end when 'start' is
not smaller than 'end'.
Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
include/linux/netdevice.h | 3 +++
net/core/dev.c | 19 +++++++++++++++++++
2 files changed, 22 insertions(+)
I've asked you multiple times to add comparison with the performance
of AF_PACKET. What's the disconnect?
Sorry for missing the question. I'm not very familiar with how to run the
test based on AF_PACKET. Could you point it out for me? Thanks.
I remember the very initial version of AF_XDP was pure AF_PACKET. So
may I ask why we expect to see the comparison between them?
Pretty sure I told you this at least twice but the point of AF_XDP
is the ZC mode. Without a comparison to AF_PACKET which has similar
functionality optimizing AF_XDP copy mode seems unjustified.
I've asked you multiple times to add comparison with the performance
of AF_PACKET. What's the disconnect?
Sorry for missing the question. I'm not very familiar with how to run the
test based on AF_PACKET. Could you point it out for me? Thanks.
I remember the very initial version of AF_XDP was pure AF_PACKET. So
may I ask why we expect to see the comparison between them?
Pretty sure I told you this at least twice but the point of AF_XDP
is the ZC mode. Without a comparison to AF_PACKET which has similar
functionality optimizing AF_XDP copy mode seems unjustified.
Oh, I see. Let me confirm again that you expect to see a demo like the
copy mode of AF_PACKET v4 [1] and see the differences in performance,
right?
If AF_PACKET eventually outperforms AF_XDP, do we need to reinvent the
copy mode based on AF_PACKET?
And if a quick/simple implementation is based on AF_PACKET, it
shouldn't be that easy to use the same benchmark to see which one is
better. That means inventing a new unified benchmark tool is
necessary?
[1]: https://lore.kernel.org/all/20171031124145.9667-1-bjorn.topel@gmail.com/
Thanks,
Jason
From: Jakub Kicinski <kuba@kernel.org> Date: 2025-08-26 01:15:33
On Tue, 26 Aug 2025 08:51:24 +0800 Jason Xing wrote:
quoted
quoted
Sorry for missing the question. I'm not very familiar with how to run the
test based on AF_PACKET. Could you point it out for me? Thanks.
I remember the very initial version of AF_XDP was pure AF_PACKET. So
may I ask why we expect to see the comparison between them?
Pretty sure I told you this at least twice but the point of AF_XDP
is the ZC mode. Without a comparison to AF_PACKET which has similar
functionality optimizing AF_XDP copy mode seems unjustified.
Oh, I see. Let me confirm again that you expect to see a demo like the
copy mode of AF_PACKET v4 [1] and see the differences in performance,
right?
If AF_PACKET eventually outperforms AF_XDP, do we need to reinvent the
copy mode based on AF_PACKET?
And if a quick/simple implementation is based on AF_PACKET, it
shouldn't be that easy to use the same benchmark to see which one is
better. That means inventing a new unified benchmark tool is
necessary?
To be honest I suspect you can get an LLM to convert your AF_XDP test
to use AF_PACKET..
From: Jason Xing <hidden> Date: 2025-08-26 01:49:48
On Tue, Aug 26, 2025 at 9:15 AM Jakub Kicinski [off-list ref] wrote:
On Tue, 26 Aug 2025 08:51:24 +0800 Jason Xing wrote:
quoted
quoted
quoted
Sorry for missing the question. I'm not very familiar with how to run the
test based on AF_PACKET. Could you point it out for me? Thanks.
I remember the very initial version of AF_XDP was pure AF_PACKET. So
may I ask why we expect to see the comparison between them?
Pretty sure I told you this at least twice but the point of AF_XDP
is the ZC mode. Without a comparison to AF_PACKET which has similar
functionality optimizing AF_XDP copy mode seems unjustified.
Oh, I see. Let me confirm again that you expect to see a demo like the
copy mode of AF_PACKET v4 [1] and see the differences in performance,
right?
If AF_PACKET eventually outperforms AF_XDP, do we need to reinvent the
copy mode based on AF_PACKET?
And if a quick/simple implementation is based on AF_PACKET, it
shouldn't be that easy to use the same benchmark to see which one is
better. That means inventing a new unified benchmark tool is
necessary?
To be honest I suspect you can get an LLM to convert your AF_XDP test
to use AF_PACKET..
Okay, allow me to spend more time on af_packet before getting my hands
dirty... Converting xdpsock should not be that easy, I feel... But I
will give it a try first.
Thanks,
Jason
Have you tried napi_skb_cache_get_bulk()? Depending on the workload, it
may give better perf numbers.
Sure, my initial try is using this interface. But later I want to see
a standalone cache belonging to xsk. The whole xsk_alloc_batch_skb
function I added is quite similar to napi_skb_cache_get_bulk(), to
some extent.
And if using napi_xxx(), we need a lock to avoid the race between this
context and softirq context on the same core.
Thanks,
Jason
Have you tried napi_skb_cache_get_bulk()? Depending on the workload, it
may give better perf numbers.
Sure, my initial try is using this interface. But later I want to see
a standalone cache belonging to xsk. The whole xsk_alloc_batch_skb
function I added is quite similar to napi_skb_cache_get_bulk(), to
some extent.
And if using napi_xxx(), we need a lock to avoid the race between this
context and softirq context on the same core.
Are you saying this particular function is not run in the softirq
context? I thought all Tx is done in BH.
If it's not BH, then ignore my suggestion -- napi_skb_cache_get_bulk()
requires BH, that's true.
Have you tried napi_skb_cache_get_bulk()? Depending on the workload, it
may give better perf numbers.
Sure, my initial try is using this interface. But later I want to see
a standalone cache belonging to xsk. The whole xsk_alloc_batch_skb
function I added is quite similar to napi_skb_cache_get_bulk(), to
some extent.
And if using napi_xxx(), we need a lock to avoid the race between this
context and softirq context on the same core.
Are you saying this particular function is not run in the softirq
No, it runs in process context. Please see this chain:
sendto->__xsk_generic_xmit-> (allocating skbs function handling).
Thanks,
Jason
context? I thought all Tx is done in BH.
If it's not BH, then ignore my suggestion -- napi_skb_cache_get_bulk()
requires BH, that's true.