From: Alexander Lobakin <hidden> Date: 2021-02-10 16:30:18
Currently, all sorts of skb allocation always do allocate
skbuff_heads one by one via kmem_cache_alloc().
On the other hand, we have percpu napi_alloc_cache to store
skbuff_heads queued up for freeing and flush them by bulks.
We can use this cache not only for bulk-wiping, but also to obtain
heads for new skbs and avoid unconditional allocations, as well as
for bulk-allocating (like XDP's cpumap code and veth driver already
do).
As this might affect latencies, cache pressure and lots of hardware
and driver-dependent stuff, this new feature is mostly optional and
can be issued via:
- a new napi_build_skb() function (as a replacement for build_skb());
- existing {,__}napi_alloc_skb() and napi_get_frags() functions;
- __alloc_skb() with passing SKB_ALLOC_NAPI in flags.
iperf3 showed 35-70 Mbps bumps for both TCP and UDP while performing
VLAN NAT on 1.2 GHz MIPS board. The boost is likely to be bigger
on more powerful hosts and NICs with tens of Mpps.
Note on skbuff_heads from distant slabs or pfmemalloc'ed slabs:
- kmalloc()/kmem_cache_alloc() itself allows by default allocating
memory from the remote nodes to defragment their slabs. This is
controlled by sysctl, but according to this, skbuff_head from a
remote node is an OK case;
- The easiest way to check if the slab of skbuff_head is remote or
pfmemalloc'ed is:
if (!dev_page_is_reusable(virt_to_head_page(skb)))
/* drop it */;
...*but*, regarding that most slabs are built of compound pages,
virt_to_head_page() will hit unlikely-branch every single call.
This check costed at least 20 Mbps in test scenarios and seems
like it'd be better to _not_ do this.
Since v3 [2]:
- make the feature mostly optional, so driver developers could
decide whether to use it or not (Paolo Abeni).
This reuses the old flag for __alloc_skb() and introduces
a new napi_build_skb();
- reduce bulk-allocation size from 32 to 16 elements (also Paolo).
This equals to the value of XDP's devmap and veth batch processing
(which were tested a lot) and should be sane enough;
- don't waste cycles on explicit in_serving_softirq() check.
Since v2 [1]:
- also cover {,__}alloc_skb() and {,__}build_skb() cases (became handy
after the changes that pass tiny skbs requests to kmalloc layer);
- cover the cache with KASAN instrumentation (suggested by Eric
Dumazet, help of Dmitry Vyukov);
- completely drop redundant __kfree_skb_flush() (also Eric);
- lots of code cleanups;
- expand the commit message with NUMA and pfmemalloc points (Jakub).
Since v1 [0]:
- use one unified cache instead of two separate to greatly simplify
the logics and reduce hotpath overhead (Edward Cree);
- new: recycle also GRO_MERGED_FREE skbs instead of immediate
freeing;
- correct performance numbers after optimizations and performing
lots of tests for different use cases.
[0] https://lore.kernel.org/netdev/20210111182655.12159-1-alobakin@pm.me
[1] https://lore.kernel.org/netdev/20210113133523.39205-1-alobakin@pm.me
[2] https://lore.kernel.org/netdev/20210209204533.327360-1-alobakin@pm.me
Alexander Lobakin (11):
skbuff: move __alloc_skb() next to the other skb allocation functions
skbuff: simplify kmalloc_reserve()
skbuff: make __build_skb_around() return void
skbuff: simplify __alloc_skb() a bit
skbuff: use __build_skb_around() in __alloc_skb()
skbuff: remove __kfree_skb_flush()
skbuff: move NAPI cache declarations upper in the file
skbuff: introduce {,__}napi_build_skb() which reuses NAPI cache heads
skbuff: allow to optionally use NAPI cache from __alloc_skb()
skbuff: allow to use NAPI cache from __napi_alloc_skb()
skbuff: queue NAPI_MERGED_FREE skbs into NAPI cache instead of freeing
include/linux/skbuff.h | 4 +-
net/core/dev.c | 15 +-
net/core/skbuff.c | 429 +++++++++++++++++++++++------------------
3 files changed, 243 insertions(+), 205 deletions(-)
--
2.30.1
From: Alexander Lobakin <hidden> Date: 2021-02-10 16:30:54
In preparation before reusing several functions in all three skb
allocation variants, move __alloc_skb() next to the
__netdev_alloc_skb() and __napi_alloc_skb().
No functional changes.
Signed-off-by: Alexander Lobakin <redacted>
---
net/core/skbuff.c | 284 +++++++++++++++++++++++-----------------------
1 file changed, 142 insertions(+), 142 deletions(-)
@@ -119,148 +119,6 @@ static void skb_under_panic(struct sk_buff *skb, unsigned int sz, void *addr)skb_panic(skb,sz,addr,__func__);}-/*-*kmalloc_reserveisawrapperaroundkmalloc_node_track_callerthattells-*thecallerifemergencypfmemallocreservesarebeingused.Ifitisand-*thesocketislaterfoundtobeSOCK_MEMALLOCthenPFMEMALLOCreserves-*maybeused.Otherwise,thepacketdatamaybediscardeduntilenough-*memoryisfree-*/-#define kmalloc_reserve(size, gfp, node, pfmemalloc) \-__kmalloc_reserve(size,gfp,node,_RET_IP_,pfmemalloc)--staticvoid*__kmalloc_reserve(size_tsize,gfp_tflags,intnode,-unsignedlongip,bool*pfmemalloc)-{-void*obj;-boolret_pfmemalloc=false;--/*-*Tryaregularallocation,whenthatfailsandwe'renotentitled-*tothereserves,fail.-*/-obj=kmalloc_node_track_caller(size,-flags|__GFP_NOMEMALLOC|__GFP_NOWARN,-node);-if(obj||!(gfp_pfmemalloc_allowed(flags)))-gotoout;--/* Try again but now we are using pfmemalloc reserves */-ret_pfmemalloc=true;-obj=kmalloc_node_track_caller(size,flags,node);--out:-if(pfmemalloc)-*pfmemalloc=ret_pfmemalloc;--returnobj;-}--/* Allocate a new skbuff. We do this ourselves so we can fill in a few-*'private'fieldsandalsodomemorystatisticstofindallthe-*[BEEP]leaks.-*-*/--/**-*__alloc_skb-allocateanetworkbuffer-*@size:sizetoallocate-*@gfp_mask:allocationmask-*@flags:IfSKB_ALLOC_FCLONEisset,allocatefromfclonecache-*insteadofheadcacheandallocateacloned(child)skb.-*IfSKB_ALLOC_RXisset,__GFP_MEMALLOCwillbeusedfor-*allocationsincasethedataisrequiredforwriteback-*@node:numanodetoallocatememoryon-*-*Allocateanew&sk_buff.Thereturnedbufferhasnoheadroomanda-*tailroomofatleastsizebytes.Theobjecthasareferencecount-*ofone.Thereturnisthebuffer.Onafailurethereturnis%NULL.-*-*Buffersmayonlybeallocatedfrominterruptsusinga@gfp_maskof-*%GFP_ATOMIC.-*/-structsk_buff*__alloc_skb(unsignedintsize,gfp_tgfp_mask,-intflags,intnode)-{-structkmem_cache*cache;-structskb_shared_info*shinfo;-structsk_buff*skb;-u8*data;-boolpfmemalloc;--cache=(flags&SKB_ALLOC_FCLONE)-?skbuff_fclone_cache:skbuff_head_cache;--if(sk_memalloc_socks()&&(flags&SKB_ALLOC_RX))-gfp_mask|=__GFP_MEMALLOC;--/* Get the HEAD */-skb=kmem_cache_alloc_node(cache,gfp_mask&~__GFP_DMA,node);-if(!skb)-gotoout;-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.-*/-size=SKB_DATA_ALIGN(size);-size+=SKB_DATA_ALIGN(sizeof(structskb_shared_info));-data=kmalloc_reserve(size,gfp_mask,node,&pfmemalloc);-if(!data)-gotonodata;-/* kmalloc(size) might give us more room than requested.-*Putskb_shared_infoexactlyattheendofallocatedzone,-*toallowmaxpossiblefillingbeforereallocation.-*/-size=SKB_WITH_OVERHEAD(ksize(data));-prefetchw(data+size);--/*-*Onlyclearthosefieldsweneedtoclear,notthosethatwewill-*actuallyinitialisebelow.Hence,don'tputanymorefieldsafter-*thetailpointerinstructsk_buff!-*/-memset(skb,0,offsetof(structsk_buff,tail));-/* Account for allocated memory : skb + skb->head */-skb->truesize=SKB_TRUESIZE(size);-skb->pfmemalloc=pfmemalloc;-refcount_set(&skb->users,1);-skb->head=data;-skb->data=data;-skb_reset_tail_pointer(skb);-skb->end=skb->tail+size;-skb->mac_header=(typeof(skb->mac_header))~0U;-skb->transport_header=(typeof(skb->transport_header))~0U;--/* make sure we initialize shinfo sequentially */-shinfo=skb_shinfo(skb);-memset(shinfo,0,offsetof(structskb_shared_info,dataref));-atomic_set(&shinfo->dataref,1);--if(flags&SKB_ALLOC_FCLONE){-structsk_buff_fclones*fclones;--fclones=container_of(skb,structsk_buff_fclones,skb1);--skb->fclone=SKB_FCLONE_ORIG;-refcount_set(&fclones->fclone_ref,1);--fclones->skb2.fclone=SKB_FCLONE_CLONE;-}--skb_set_kcov_handle(skb,kcov_common_handle());--out:-returnskb;-nodata:-kmem_cache_free(cache,skb);-skb=NULL;-gotoout;-}-EXPORT_SYMBOL(__alloc_skb);-/* Caller must provide SKB that is memset cleared */staticstructsk_buff*__build_skb_around(structsk_buff*skb,void*data,unsignedintfrag_size)
@@ -408,6 +266,148 @@ void *__netdev_alloc_frag_align(unsigned int fragsz, unsigned int align_mask)}EXPORT_SYMBOL(__netdev_alloc_frag_align);+/*+*kmalloc_reserveisawrapperaroundkmalloc_node_track_callerthattells+*thecallerifemergencypfmemallocreservesarebeingused.Ifitisand+*thesocketislaterfoundtobeSOCK_MEMALLOCthenPFMEMALLOCreserves+*maybeused.Otherwise,thepacketdatamaybediscardeduntilenough+*memoryisfree+*/+#define kmalloc_reserve(size, gfp, node, pfmemalloc) \+__kmalloc_reserve(size,gfp,node,_RET_IP_,pfmemalloc)++staticvoid*__kmalloc_reserve(size_tsize,gfp_tflags,intnode,+unsignedlongip,bool*pfmemalloc)+{+void*obj;+boolret_pfmemalloc=false;++/*+*Tryaregularallocation,whenthatfailsandwe'renotentitled+*tothereserves,fail.+*/+obj=kmalloc_node_track_caller(size,+flags|__GFP_NOMEMALLOC|__GFP_NOWARN,+node);+if(obj||!(gfp_pfmemalloc_allowed(flags)))+gotoout;++/* Try again but now we are using pfmemalloc reserves */+ret_pfmemalloc=true;+obj=kmalloc_node_track_caller(size,flags,node);++out:+if(pfmemalloc)+*pfmemalloc=ret_pfmemalloc;++returnobj;+}++/* Allocate a new skbuff. We do this ourselves so we can fill in a few+*'private'fieldsandalsodomemorystatisticstofindallthe+*[BEEP]leaks.+*+*/++/**+*__alloc_skb-allocateanetworkbuffer+*@size:sizetoallocate+*@gfp_mask:allocationmask+*@flags:IfSKB_ALLOC_FCLONEisset,allocatefromfclonecache+*insteadofheadcacheandallocateacloned(child)skb.+*IfSKB_ALLOC_RXisset,__GFP_MEMALLOCwillbeusedfor+*allocationsincasethedataisrequiredforwriteback+*@node:numanodetoallocatememoryon+*+*Allocateanew&sk_buff.Thereturnedbufferhasnoheadroomanda+*tailroomofatleastsizebytes.Theobjecthasareferencecount+*ofone.Thereturnisthebuffer.Onafailurethereturnis%NULL.+*+*Buffersmayonlybeallocatedfrominterruptsusinga@gfp_maskof+*%GFP_ATOMIC.+*/+structsk_buff*__alloc_skb(unsignedintsize,gfp_tgfp_mask,+intflags,intnode)+{+structkmem_cache*cache;+structskb_shared_info*shinfo;+structsk_buff*skb;+u8*data;+boolpfmemalloc;++cache=(flags&SKB_ALLOC_FCLONE)+?skbuff_fclone_cache:skbuff_head_cache;++if(sk_memalloc_socks()&&(flags&SKB_ALLOC_RX))+gfp_mask|=__GFP_MEMALLOC;++/* Get the HEAD */+skb=kmem_cache_alloc_node(cache,gfp_mask&~__GFP_DMA,node);+if(!skb)+gotoout;+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.+*/+size=SKB_DATA_ALIGN(size);+size+=SKB_DATA_ALIGN(sizeof(structskb_shared_info));+data=kmalloc_reserve(size,gfp_mask,node,&pfmemalloc);+if(!data)+gotonodata;+/* kmalloc(size) might give us more room than requested.+*Putskb_shared_infoexactlyattheendofallocatedzone,+*toallowmaxpossiblefillingbeforereallocation.+*/+size=SKB_WITH_OVERHEAD(ksize(data));+prefetchw(data+size);++/*+*Onlyclearthosefieldsweneedtoclear,notthosethatwewill+*actuallyinitialisebelow.Hence,don'tputanymorefieldsafter+*thetailpointerinstructsk_buff!+*/+memset(skb,0,offsetof(structsk_buff,tail));+/* Account for allocated memory : skb + skb->head */+skb->truesize=SKB_TRUESIZE(size);+skb->pfmemalloc=pfmemalloc;+refcount_set(&skb->users,1);+skb->head=data;+skb->data=data;+skb_reset_tail_pointer(skb);+skb->end=skb->tail+size;+skb->mac_header=(typeof(skb->mac_header))~0U;+skb->transport_header=(typeof(skb->transport_header))~0U;++/* make sure we initialize shinfo sequentially */+shinfo=skb_shinfo(skb);+memset(shinfo,0,offsetof(structskb_shared_info,dataref));+atomic_set(&shinfo->dataref,1);++if(flags&SKB_ALLOC_FCLONE){+structsk_buff_fclones*fclones;++fclones=container_of(skb,structsk_buff_fclones,skb1);++skb->fclone=SKB_FCLONE_ORIG;+refcount_set(&fclones->fclone_ref,1);++fclones->skb2.fclone=SKB_FCLONE_CLONE;+}++skb_set_kcov_handle(skb,kcov_common_handle());++out:+returnskb;+nodata:+kmem_cache_free(cache,skb);+skb=NULL;+gotoout;+}+EXPORT_SYMBOL(__alloc_skb);+/***__netdev_alloc_skb-allocateanskbuffforrxonaspecificdevice*@dev:networkdevicetoreceiveon
From: Alexander Lobakin <hidden> Date: 2021-02-10 16:31:22
Eversince the introduction of __kmalloc_reserve(), "ip" argument
hasn't been used. _RET_IP_ is embedded inside
kmalloc_node_track_caller().
Remove the redundant macro and rename the function after it.
Signed-off-by: Alexander Lobakin <redacted>
---
net/core/skbuff.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
From: Alexander Lobakin <hidden> Date: 2021-02-10 16:32:42
__build_skb_around() can never fail and always returns passed skb.
Make it return void to simplify and optimize the code.
Signed-off-by: Alexander Lobakin <redacted>
---
net/core/skbuff.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
@@ -120,8 +120,8 @@ static void skb_under_panic(struct sk_buff *skb, unsigned int sz, void *addr)}/* Caller must provide SKB that is memset cleared */-staticstructsk_buff*__build_skb_around(structsk_buff*skb,-void*data,unsignedintfrag_size)+staticvoid__build_skb_around(structsk_buff*skb,void*data,+unsignedintfrag_size){structskb_shared_info*shinfo;unsignedintsize=frag_size?:ksize(data);
@@ -176,8 +174,9 @@ struct sk_buff *__build_skb(void *data, unsigned int frag_size)returnNULL;memset(skb,0,offsetof(structsk_buff,tail));+__build_skb_around(skb,data,frag_size);-return__build_skb_around(skb,data,frag_size);+returnskb;}/* build_skb() is wrapper over __build_skb(), that specifically
From: Alexander Lobakin <hidden> Date: 2021-02-10 16:33:46
This function isn't much needed as NAPI skb queue gets bulk-freed
anyway when there's no more room, and even may reduce the efficiency
of bulk operations.
It will be even less needed after reusing skb cache on allocation path,
so remove it and this way lighten network softirqs a bit.
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Alexander Lobakin <redacted>
---
include/linux/skbuff.h | 1 -
net/core/dev.c | 6 +-----
net/core/skbuff.c | 12 ------------
3 files changed, 1 insertion(+), 18 deletions(-)
From: Alexander Lobakin <hidden> Date: 2021-02-10 16:34:43
Use unlikely() annotations for skbuff_head and data similarly to the
two other allocation functions and remove totally redundant goto.
Signed-off-by: Alexander Lobakin <redacted>
---
net/core/skbuff.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
@@ -339,8 +339,8 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,/* Get the HEAD */skb=kmem_cache_alloc_node(cache,gfp_mask&~__GFP_DMA,node);-if(!skb)-gotoout;+if(unlikely(!skb))+returnNULL;prefetchw(skb);/* We do our best to align skb_shared_info on a separate cache
@@ -351,7 +351,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,size=SKB_DATA_ALIGN(size);size+=SKB_DATA_ALIGN(sizeof(structskb_shared_info));data=kmalloc_reserve(size,gfp_mask,node,&pfmemalloc);-if(!data)+if(unlikely(!data))gotonodata;/* kmalloc(size) might give us more room than requested.*Putskb_shared_infoexactlyattheendofallocatedzone,
From: Alexander Lobakin <hidden> Date: 2021-02-10 16:35:51
NAPI cache structures will be used for allocating skbuff_heads,
so move their declarations a bit upper.
Signed-off-by: Alexander Lobakin <redacted>
---
net/core/skbuff.c | 90 +++++++++++++++++++++++------------------------
1 file changed, 45 insertions(+), 45 deletions(-)
@@ -119,6 +119,51 @@ static void skb_under_panic(struct sk_buff *skb, unsigned int sz, void *addr)skb_panic(skb,sz,addr,__func__);}+#define NAPI_SKB_CACHE_SIZE 64++structnapi_alloc_cache{+structpage_frag_cachepage;+unsignedintskb_count;+void*skb_cache[NAPI_SKB_CACHE_SIZE];+};++staticDEFINE_PER_CPU(structpage_frag_cache,netdev_alloc_cache);+staticDEFINE_PER_CPU(structnapi_alloc_cache,napi_alloc_cache);++staticvoid*__alloc_frag_align(unsignedintfragsz,gfp_tgfp_mask,+unsignedintalign_mask)+{+structnapi_alloc_cache*nc=this_cpu_ptr(&napi_alloc_cache);++returnpage_frag_alloc_align(&nc->page,fragsz,gfp_mask,align_mask);+}++void*__napi_alloc_frag_align(unsignedintfragsz,unsignedintalign_mask)+{+fragsz=SKB_DATA_ALIGN(fragsz);++return__alloc_frag_align(fragsz,GFP_ATOMIC,align_mask);+}+EXPORT_SYMBOL(__napi_alloc_frag_align);++void*__netdev_alloc_frag_align(unsignedintfragsz,unsignedintalign_mask)+{+structpage_frag_cache*nc;+void*data;++fragsz=SKB_DATA_ALIGN(fragsz);+if(in_irq()||irqs_disabled()){+nc=this_cpu_ptr(&netdev_alloc_cache);+data=page_frag_alloc_align(nc,fragsz,GFP_ATOMIC,align_mask);+}else{+local_bh_disable();+data=__alloc_frag_align(fragsz,GFP_ATOMIC,align_mask);+local_bh_enable();+}+returndata;+}+EXPORT_SYMBOL(__netdev_alloc_frag_align);+/* Caller must provide SKB that is memset cleared */staticvoid__build_skb_around(structsk_buff*skb,void*data,unsignedintfrag_size)
From: Alexander Lobakin <hidden> Date: 2021-02-10 16:35:56
Instead of just bulk-flushing skbuff_heads queued up through
napi_consume_skb() or __kfree_skb_defer(), try to reuse them
on allocation path.
If the cache is empty on allocation, bulk-allocate the first
16 elements, which is more efficient than per-skb allocation.
If the cache is full on freeing, bulk-wipe the second half of
the cache (32 elements).
This also includes custom KASAN poisoning/unpoisoning to be
double sure there are no use-after-free cases.
To not change current behaviour, introduce a new function,
napi_build_skb(), to optionally use a new approach later
in drivers.
Note on selected bulk size, 16:
- this equals to XDP_BULK_QUEUE_SIZE, DEV_MAP_BULK_SIZE
and especially VETH_XDP_BATCH, which is also used to
bulk-allocate skbuff_heads and was tested on powerful
setups;
- this also showed the best performance in the actual
test series (from the array of {8, 16, 32}).
Suggested-by: Edward Cree <ecree.xilinx@gmail.com> # Divide on two halves
Suggested-by: Eric Dumazet <edumazet@google.com> # KASAN poisoning
Cc: Dmitry Vyukov <dvyukov@google.com> # Help with KASAN
Cc: Paolo Abeni <pabeni@redhat.com> # Reduced batch size
Signed-off-by: Alexander Lobakin <redacted>
---
include/linux/skbuff.h | 2 +
net/core/skbuff.c | 94 ++++++++++++++++++++++++++++++++++++------
2 files changed, 83 insertions(+), 13 deletions(-)
@@ -164,6 +166,25 @@ void *__netdev_alloc_frag_align(unsigned int fragsz, unsigned int align_mask)}EXPORT_SYMBOL(__netdev_alloc_frag_align);+staticstructsk_buff*napi_skb_cache_get(void)+{+structnapi_alloc_cache*nc=this_cpu_ptr(&napi_alloc_cache);+structsk_buff*skb;++if(unlikely(!nc->skb_count))+nc->skb_count=kmem_cache_alloc_bulk(skbuff_head_cache,+GFP_ATOMIC,+NAPI_SKB_CACHE_BULK,+nc->skb_cache);+if(unlikely(!nc->skb_count))+returnNULL;++skb=nc->skb_cache[--nc->skb_count];+kasan_unpoison_object_data(skbuff_head_cache,skb);++returnskb;+}+/* Caller must provide SKB that is memset cleared */staticvoid__build_skb_around(structsk_buff*skb,void*data,unsignedintfrag_size)
@@ -838,31 +906,31 @@ void __consume_stateless_skb(struct sk_buff *skb)kfree_skbmem(skb);}-staticinlinevoid_kfree_skb_defer(structsk_buff*skb)+staticvoidnapi_skb_cache_put(structsk_buff*skb){structnapi_alloc_cache*nc=this_cpu_ptr(&napi_alloc_cache);+u32i;/* drop skb->head and call any destructors for packet */skb_release_all(skb);-/* record skb to CPU local list */+kasan_poison_object_data(skbuff_head_cache,skb);nc->skb_cache[nc->skb_count++]=skb;-#ifdef CONFIG_SLUB-/* SLUB writes into objects when freeing */-prefetchw(skb);-#endif--/* flush skb_cache if it is filled */if(unlikely(nc->skb_count==NAPI_SKB_CACHE_SIZE)){-kmem_cache_free_bulk(skbuff_head_cache,NAPI_SKB_CACHE_SIZE,-nc->skb_cache);-nc->skb_count=0;+for(i=NAPI_SKB_CACHE_HALF;i<NAPI_SKB_CACHE_SIZE;i++)+kasan_unpoison_object_data(skbuff_head_cache,+nc->skb_cache[i]);++kmem_cache_free_bulk(skbuff_head_cache,NAPI_SKB_CACHE_HALF,+nc->skb_cache+NAPI_SKB_CACHE_HALF);+nc->skb_count=NAPI_SKB_CACHE_HALF;}}+void__kfree_skb_defer(structsk_buff*skb){-_kfree_skb_defer(skb);+napi_skb_cache_put(skb);}voidnapi_consume_skb(structsk_buff*skb,intbudget)
@@ -887,7 +955,7 @@ void napi_consume_skb(struct sk_buff *skb, int budget)return;}-_kfree_skb_defer(skb);+napi_skb_cache_put(skb);}EXPORT_SYMBOL(napi_consume_skb);
From: Alexander Lobakin <hidden> Date: 2021-02-10 16:36:32
Reuse the old and forgotten SKB_ALLOC_NAPI to add an option to get
an skbuff_head from the NAPI cache instead of inplace allocation
inside __alloc_skb().
This implies that the function is called from softirq or BH-off
context, not for allocating a clone or from a distant node.
Signed-off-by: Alexander Lobakin <redacted>
---
net/core/skbuff.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
@@ -397,15 +397,20 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,structsk_buff*skb;u8*data;boolpfmemalloc;+boolclone;-cache=(flags&SKB_ALLOC_FCLONE)-?skbuff_fclone_cache:skbuff_head_cache;+clone=!!(flags&SKB_ALLOC_FCLONE);+cache=clone?skbuff_fclone_cache:skbuff_head_cache;if(sk_memalloc_socks()&&(flags&SKB_ALLOC_RX))gfp_mask|=__GFP_MEMALLOC;/* Get the HEAD */-skb=kmem_cache_alloc_node(cache,gfp_mask&~__GFP_DMA,node);+if(!clone&&(flags&SKB_ALLOC_NAPI)&&+likely(node==NUMA_NO_NODE||node==numa_mem_id()))+skb=napi_skb_cache_get();+else+skb=kmem_cache_alloc_node(cache,gfp_mask&~GFP_DMA,node);if(unlikely(!skb))returnNULL;prefetchw(skb);
From: Alexander Lobakin <hidden> Date: 2021-02-10 16:38:05
{,__}napi_alloc_skb() is mostly used either for optional non-linear
receive methods (usually controlled via Ethtool private flags and off
by default) and/or for Rx copybreaks.
Use __napi_build_skb() here for obtaining skbuff_heads from NAPI cache
instead of inplace allocations. This includes both kmalloc and page
frag paths.
Signed-off-by: Alexander Lobakin <redacted>
---
net/core/skbuff.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
From: Alexander Lobakin <hidden> Date: 2021-02-10 16:38:06
napi_frags_finish() and napi_skb_finish() can only be called inside
NAPI Rx context, so we can feed NAPI cache with skbuff_heads that
got NAPI_MERGED_FREE verdict instead of immediate freeing.
Replace __kfree_skb() with __kfree_skb_defer() in napi_skb_finish()
and move napi_skb_free_stolen_head() to skbuff.c, so it can drop skbs
to NAPI cache.
As many drivers call napi_alloc_skb()/napi_get_frags() on their
receive path, this becomes especially useful.
Signed-off-by: Alexander Lobakin <redacted>
---
include/linux/skbuff.h | 1 +
net/core/dev.c | 9 +--------
net/core/skbuff.c | 12 +++++++++---
3 files changed, 11 insertions(+), 11 deletions(-)
@@ -917,9 +917,6 @@ static void napi_skb_cache_put(struct sk_buff *skb)structnapi_alloc_cache*nc=this_cpu_ptr(&napi_alloc_cache);u32i;-/* drop skb->head and call any destructors for packet */-skb_release_all(skb);-kasan_poison_object_data(skbuff_head_cache,skb);nc->skb_cache[nc->skb_count++]=skb;
net/core/dev.c:7012:4: error: implicit declaration of function '__kfree_skb_flush'; did you mean '__kfree_skb_defer'? [-Werror=implicit-function-declaration]
7012 | __kfree_skb_flush();
| ^~~~~~~~~~~~~~~~~
| __kfree_skb_defer
cc1: some warnings being treated as errors
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for SND_ATMEL_SOC_PDC
Depends on SOUND && !UML && SND && SND_SOC && SND_ATMEL_SOC && HAS_DMA
Selected by
- SND_ATMEL_SOC_SSC && SOUND && !UML && SND && SND_SOC && SND_ATMEL_SOC
- SND_ATMEL_SOC_SSC_PDC && SOUND && !UML && SND && SND_SOC && SND_ATMEL_SOC && ATMEL_SSC
vim +7012 net/core/dev.c
29863d41bb6e1d Wei Wang 2021-02-08 6996
29863d41bb6e1d Wei Wang 2021-02-08 6997 static int napi_threaded_poll(void *data)
29863d41bb6e1d Wei Wang 2021-02-08 6998 {
29863d41bb6e1d Wei Wang 2021-02-08 6999 struct napi_struct *napi = data;
29863d41bb6e1d Wei Wang 2021-02-08 7000 void *have;
29863d41bb6e1d Wei Wang 2021-02-08 7001
29863d41bb6e1d Wei Wang 2021-02-08 7002 while (!napi_thread_wait(napi)) {
29863d41bb6e1d Wei Wang 2021-02-08 7003 for (;;) {
29863d41bb6e1d Wei Wang 2021-02-08 7004 bool repoll = false;
29863d41bb6e1d Wei Wang 2021-02-08 7005
29863d41bb6e1d Wei Wang 2021-02-08 7006 local_bh_disable();
29863d41bb6e1d Wei Wang 2021-02-08 7007
29863d41bb6e1d Wei Wang 2021-02-08 7008 have = netpoll_poll_lock(napi);
29863d41bb6e1d Wei Wang 2021-02-08 7009 __napi_poll(napi, &repoll);
29863d41bb6e1d Wei Wang 2021-02-08 7010 netpoll_poll_unlock(have);
29863d41bb6e1d Wei Wang 2021-02-08 7011
29863d41bb6e1d Wei Wang 2021-02-08 @7012 __kfree_skb_flush();
29863d41bb6e1d Wei Wang 2021-02-08 7013 local_bh_enable();
29863d41bb6e1d Wei Wang 2021-02-08 7014
29863d41bb6e1d Wei Wang 2021-02-08 7015 if (!repoll)
29863d41bb6e1d Wei Wang 2021-02-08 7016 break;
29863d41bb6e1d Wei Wang 2021-02-08 7017
29863d41bb6e1d Wei Wang 2021-02-08 7018 cond_resched();
29863d41bb6e1d Wei Wang 2021-02-08 7019 }
29863d41bb6e1d Wei Wang 2021-02-08 7020 }
29863d41bb6e1d Wei Wang 2021-02-08 7021 return 0;
29863d41bb6e1d Wei Wang 2021-02-08 7022 }
29863d41bb6e1d Wei Wang 2021-02-08 7023
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
From: kernel test robot <hidden> Date: 2021-02-11 00:20:29
Hi Alexander,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Alexander-Lobakin/skbuff-introduce-skbuff_heads-bulking-and-reusing/20210211-004041
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git de1db4a6ed6241e34cab0e5059d4b56f6bae39b9
config: s390-randconfig-r025-20210209 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project c9439ca36342fb6013187d0a69aef92736951476)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install s390 cross compiling tool for clang build
# apt-get install binutils-s390x-linux-gnu
# https://github.com/0day-ci/linux/commit/6bb224307d9f31afa154a8825f9acbd8e9f6b490
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Alexander-Lobakin/skbuff-introduce-skbuff_heads-bulking-and-reusing/20210211-004041
git checkout 6bb224307d9f31afa154a8825f9acbd8e9f6b490
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <redacted>
All errors (new ones prefixed by >>):
In file included from include/linux/skbuff.h:31:
In file included from include/linux/dma-mapping.h:10:
In file included from include/linux/scatterlist.h:9:
In file included from arch/s390/include/asm/io.h:80:
include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
~~~~~~~~~~ ^
include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro '__le32_to_cpu'
#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
^
include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
___constant_swab32(x) : \
^
include/uapi/linux/swab.h:20:12: note: expanded from macro '___constant_swab32'
(((__u32)(x) & (__u32)0x0000ff00UL) << 8) | \
^
In file included from net/core/dev.c:89:
In file included from include/linux/if_ether.h:19:
In file included from include/linux/skbuff.h:31:
In file included from include/linux/dma-mapping.h:10:
In file included from include/linux/scatterlist.h:9:
In file included from arch/s390/include/asm/io.h:80:
include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
~~~~~~~~~~ ^
include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro '__le32_to_cpu'
#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
^
include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
___constant_swab32(x) : \
^
include/uapi/linux/swab.h:21:12: note: expanded from macro '___constant_swab32'
(((__u32)(x) & (__u32)0x00ff0000UL) >> 8) | \
^
In file included from net/core/dev.c:89:
In file included from include/linux/if_ether.h:19:
In file included from include/linux/skbuff.h:31:
In file included from include/linux/dma-mapping.h:10:
In file included from include/linux/scatterlist.h:9:
In file included from arch/s390/include/asm/io.h:80:
include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
~~~~~~~~~~ ^
include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro '__le32_to_cpu'
#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
^
include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
___constant_swab32(x) : \
^
include/uapi/linux/swab.h:22:12: note: expanded from macro '___constant_swab32'
(((__u32)(x) & (__u32)0xff000000UL) >> 24)))
^
In file included from net/core/dev.c:89:
In file included from include/linux/if_ether.h:19:
In file included from include/linux/skbuff.h:31:
In file included from include/linux/dma-mapping.h:10:
In file included from include/linux/scatterlist.h:9:
In file included from arch/s390/include/asm/io.h:80:
include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
~~~~~~~~~~ ^
include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro '__le32_to_cpu'
#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
^
include/uapi/linux/swab.h:120:12: note: expanded from macro '__swab32'
__fswab32(x))
^
In file included from net/core/dev.c:89:
In file included from include/linux/if_ether.h:19:
In file included from include/linux/skbuff.h:31:
In file included from include/linux/dma-mapping.h:10:
In file included from include/linux/scatterlist.h:9:
In file included from arch/s390/include/asm/io.h:80:
include/asm-generic/io.h:501:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
__raw_writeb(value, PCI_IOBASE + addr);
~~~~~~~~~~ ^
include/asm-generic/io.h:511:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
__raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr);
~~~~~~~~~~ ^
include/asm-generic/io.h:521:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
__raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr);
~~~~~~~~~~ ^
include/asm-generic/io.h:609:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
readsb(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
include/asm-generic/io.h:617:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
readsw(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
include/asm-generic/io.h:625:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
readsl(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
include/asm-generic/io.h:634:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
writesb(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
include/asm-generic/io.h:643:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
writesw(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
include/asm-generic/io.h:652:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
writesl(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
quoted
net/core/dev.c:7012:4: error: implicit declaration of function '__kfree_skb_flush' [-Werror,-Wimplicit-function-declaration]
__kfree_skb_flush();
^
20 warnings and 1 error generated.
vim +/__kfree_skb_flush +7012 net/core/dev.c
29863d41bb6e1d Wei Wang 2021-02-08 6996
29863d41bb6e1d Wei Wang 2021-02-08 6997 static int napi_threaded_poll(void *data)
29863d41bb6e1d Wei Wang 2021-02-08 6998 {
29863d41bb6e1d Wei Wang 2021-02-08 6999 struct napi_struct *napi = data;
29863d41bb6e1d Wei Wang 2021-02-08 7000 void *have;
29863d41bb6e1d Wei Wang 2021-02-08 7001
29863d41bb6e1d Wei Wang 2021-02-08 7002 while (!napi_thread_wait(napi)) {
29863d41bb6e1d Wei Wang 2021-02-08 7003 for (;;) {
29863d41bb6e1d Wei Wang 2021-02-08 7004 bool repoll = false;
29863d41bb6e1d Wei Wang 2021-02-08 7005
29863d41bb6e1d Wei Wang 2021-02-08 7006 local_bh_disable();
29863d41bb6e1d Wei Wang 2021-02-08 7007
29863d41bb6e1d Wei Wang 2021-02-08 7008 have = netpoll_poll_lock(napi);
29863d41bb6e1d Wei Wang 2021-02-08 7009 __napi_poll(napi, &repoll);
29863d41bb6e1d Wei Wang 2021-02-08 7010 netpoll_poll_unlock(have);
29863d41bb6e1d Wei Wang 2021-02-08 7011
29863d41bb6e1d Wei Wang 2021-02-08 @7012 __kfree_skb_flush();
29863d41bb6e1d Wei Wang 2021-02-08 7013 local_bh_enable();
29863d41bb6e1d Wei Wang 2021-02-08 7014
29863d41bb6e1d Wei Wang 2021-02-08 7015 if (!repoll)
29863d41bb6e1d Wei Wang 2021-02-08 7016 break;
29863d41bb6e1d Wei Wang 2021-02-08 7017
29863d41bb6e1d Wei Wang 2021-02-08 7018 cond_resched();
29863d41bb6e1d Wei Wang 2021-02-08 7019 }
29863d41bb6e1d Wei Wang 2021-02-08 7020 }
29863d41bb6e1d Wei Wang 2021-02-08 7021 return 0;
29863d41bb6e1d Wei Wang 2021-02-08 7022 }
29863d41bb6e1d Wei Wang 2021-02-08 7023
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
From: Paolo Abeni <pabeni@redhat.com> Date: 2021-02-11 10:21:50
On Wed, 2021-02-10 at 16:30 +0000, Alexander Lobakin wrote:
quoted hunk
Reuse the old and forgotten SKB_ALLOC_NAPI to add an option to get
an skbuff_head from the NAPI cache instead of inplace allocation
inside __alloc_skb().
This implies that the function is called from softirq or BH-off
context, not for allocating a clone or from a distant node.
Signed-off-by: Alexander Lobakin <redacted>
---
net/core/skbuff.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
@@ -397,15 +397,20 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,structsk_buff*skb;u8*data;boolpfmemalloc;+boolclone;-cache=(flags&SKB_ALLOC_FCLONE)-?skbuff_fclone_cache:skbuff_head_cache;+clone=!!(flags&SKB_ALLOC_FCLONE);+cache=clone?skbuff_fclone_cache:skbuff_head_cache;if(sk_memalloc_socks()&&(flags&SKB_ALLOC_RX))gfp_mask|=__GFP_MEMALLOC;/* Get the HEAD */-skb=kmem_cache_alloc_node(cache,gfp_mask&~__GFP_DMA,node);+if(!clone&&(flags&SKB_ALLOC_NAPI)&&+likely(node==NUMA_NO_NODE||node==numa_mem_id()))+skb=napi_skb_cache_get();+else+skb=kmem_cache_alloc_node(cache,gfp_mask&~GFP_DMA,node);if(unlikely(!skb))returnNULL;prefetchw(skb);
I hope the opt-in thing would have allowed leaving this code unchanged.
I see it's not trivial avoid touching this code path.
Still I think it would be nice if you would be able to let the device
driver use the cache without touching the above, which is also used
e.g. by the TCP xmit path, which in turn will not leverage the cache
(as it requires FCLONE skbs).
If I read correctly, the above chunk is needed to
allow __napi_alloc_skb() access the cache even for small skb
allocation. Good device drivers should not call alloc_skb() in the fast
path.
What about changing __napi_alloc_skb() to always use
the __napi_build_skb(), for both kmalloc and page backed skbs? That is,
always doing the 'data' allocation in __napi_alloc_skb() - either via
page_frag or via kmalloc() - and than call __napi_build_skb().
I think that should avoid adding more checks in __alloc_skb() and
should probably reduce the number of conditional used
by __napi_alloc_skb().
Thanks!
Paolo
On Wed, 10 Feb 2021 16:30:23 +0000
Alexander Lobakin [off-list ref] wrote:
Instead of just bulk-flushing skbuff_heads queued up through
napi_consume_skb() or __kfree_skb_defer(), try to reuse them
on allocation path.
Maybe you are already aware of this dynamics, but high speed NICs will
usually run the TX "cleanup" (opportunistic DMA-completion) in the napi
poll function call, and often before processing RX packets. Like
ixgbe_poll[1] calls ixgbe_clean_tx_irq() before ixgbe_clean_rx_irq().
If traffic is symmetric (or is routed-back same interface) then this
SKB recycle scheme will be highly efficient. (I had this part of my
initial patchset and tested it on ixgbe).
[1] https://elixir.bootlin.com/linux/v5.11-rc7/source/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c#L3149
quoted hunk
If the cache is empty on allocation, bulk-allocate the first
16 elements, which is more efficient than per-skb allocation.
If the cache is full on freeing, bulk-wipe the second half of
the cache (32 elements).
This also includes custom KASAN poisoning/unpoisoning to be
double sure there are no use-after-free cases.
To not change current behaviour, introduce a new function,
napi_build_skb(), to optionally use a new approach later
in drivers.
Note on selected bulk size, 16:
- this equals to XDP_BULK_QUEUE_SIZE, DEV_MAP_BULK_SIZE
and especially VETH_XDP_BATCH, which is also used to
bulk-allocate skbuff_heads and was tested on powerful
setups;
- this also showed the best performance in the actual
test series (from the array of {8, 16, 32}).
Suggested-by: Edward Cree <ecree.xilinx@gmail.com> # Divide on two halves
Suggested-by: Eric Dumazet <edumazet@google.com> # KASAN poisoning
Cc: Dmitry Vyukov <dvyukov@google.com> # Help with KASAN
Cc: Paolo Abeni <pabeni@redhat.com> # Reduced batch size
Signed-off-by: Alexander Lobakin <redacted>
---
include/linux/skbuff.h | 2 +
net/core/skbuff.c | 94 ++++++++++++++++++++++++++++++++++++------
2 files changed, 83 insertions(+), 13 deletions(-)
From: Alexander Lobakin <hidden> Date: 2021-02-11 14:32:43
From: Paolo Abeni <pabeni@redhat.com>
Date: Thu, 11 Feb 2021 11:16:40 +0100
On Wed, 2021-02-10 at 16:30 +0000, Alexander Lobakin wrote:
quoted
Reuse the old and forgotten SKB_ALLOC_NAPI to add an option to get
an skbuff_head from the NAPI cache instead of inplace allocation
inside __alloc_skb().
This implies that the function is called from softirq or BH-off
context, not for allocating a clone or from a distant node.
Signed-off-by: Alexander Lobakin <redacted>
---
net/core/skbuff.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
@@ -397,15 +397,20 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,structsk_buff*skb;u8*data;boolpfmemalloc;+boolclone;-cache=(flags&SKB_ALLOC_FCLONE)-?skbuff_fclone_cache:skbuff_head_cache;+clone=!!(flags&SKB_ALLOC_FCLONE);+cache=clone?skbuff_fclone_cache:skbuff_head_cache;if(sk_memalloc_socks()&&(flags&SKB_ALLOC_RX))gfp_mask|=__GFP_MEMALLOC;/* Get the HEAD */-skb=kmem_cache_alloc_node(cache,gfp_mask&~__GFP_DMA,node);+if(!clone&&(flags&SKB_ALLOC_NAPI)&&+likely(node==NUMA_NO_NODE||node==numa_mem_id()))+skb=napi_skb_cache_get();+else+skb=kmem_cache_alloc_node(cache,gfp_mask&~GFP_DMA,node);if(unlikely(!skb))returnNULL;prefetchw(skb);
I hope the opt-in thing would have allowed leaving this code unchanged.
I see it's not trivial avoid touching this code path.
Still I think it would be nice if you would be able to let the device
driver use the cache without touching the above, which is also used
e.g. by the TCP xmit path, which in turn will not leverage the cache
(as it requires FCLONE skbs).
If I read correctly, the above chunk is needed to
allow __napi_alloc_skb() access the cache even for small skb
allocation.
Not only. I wanted to give an ability to access the new feature
through __alloc_skb() too, not only through napi_build_skb() or
napi_alloc_skb().
And not only for drivers. As you may remember, firstly
napi_consume_skb()'s batching system landed for drivers, but then
it got used in network core code.
I think that some core parts may benefit from reusing the NAPI
caches. We'll only see it later.
It's not as complex as it may seem. NUMA check is cheap and tends
to be true for the vast majority of cases. Check for fclone is
already present in baseline code, even two times through the function.
So it's mostly about (flags & SKB_ALLOC_NAPI).
Good device drivers should not call alloc_skb() in the fast
path.
Not really. Several enterprise NIC drivers use __alloc_skb() and
alloc_skb(): ChelsIO and Mellanox for inline TLS, Netronome etc.
Lots of RDMA and wireless drivers (not the legacy ones), too.
__alloc_skb() gives you more control on NUMA node and needed skb
headroom, so it's still sometimes useful in drivers.
What about changing __napi_alloc_skb() to always use
the __napi_build_skb(), for both kmalloc and page backed skbs? That is,
always doing the 'data' allocation in __napi_alloc_skb() - either via
page_frag or via kmalloc() - and than call __napi_build_skb().
I think that should avoid adding more checks in __alloc_skb() and
should probably reduce the number of conditional used
by __napi_alloc_skb().
I thought of this too. But this will introduce conditional branch
to set or not skb->head_frag. So one branch less in __alloc_skb(),
one branch more here, and we also lose the ability to __alloc_skb()
with decached head.
On Wed, 10 Feb 2021 16:30:23 +0000
Alexander Lobakin [off-list ref] wrote:
quoted
Instead of just bulk-flushing skbuff_heads queued up through
napi_consume_skb() or __kfree_skb_defer(), try to reuse them
on allocation path.
Maybe you are already aware of this dynamics, but high speed NICs will
usually run the TX "cleanup" (opportunistic DMA-completion) in the napi
poll function call, and often before processing RX packets. Like
ixgbe_poll[1] calls ixgbe_clean_tx_irq() before ixgbe_clean_rx_irq().
Sure. 1G MIPS is my home project (I'll likely migrate to ARM64 cluster
in 2-3 months). I mostly work with 10-100G NICs at work.
That's exactly why I introduced this feature. Firstly driver enriches
the cache with the consumed skbs from Tx completion queue, and then
it just decaches them back on Rx completion cycle. That's how things
worked most of the time on my test setup.
The reason why Paolo proposed this as an option, and why I agreed
it's safer to do instead of unconditional switching, is that
different platforms and setup may react differently on this.
We don't have an ability to test the entire zoo, so we propose
an option for driver and network core developers to test and use
"on demand".
As I wrote in reply to Paolo, there might be cases when even the
core networking code may benefit from this.
quoted
If the cache is empty on allocation, bulk-allocate the first
16 elements, which is more efficient than per-skb allocation.
If the cache is full on freeing, bulk-wipe the second half of
the cache (32 elements).
This also includes custom KASAN poisoning/unpoisoning to be
double sure there are no use-after-free cases.
To not change current behaviour, introduce a new function,
napi_build_skb(), to optionally use a new approach later
in drivers.
Note on selected bulk size, 16:
- this equals to XDP_BULK_QUEUE_SIZE, DEV_MAP_BULK_SIZE
and especially VETH_XDP_BATCH, which is also used to
bulk-allocate skbuff_heads and was tested on powerful
setups;
- this also showed the best performance in the actual
test series (from the array of {8, 16, 32}).
Suggested-by: Edward Cree <ecree.xilinx@gmail.com> # Divide on two halves
Suggested-by: Eric Dumazet <edumazet@google.com> # KASAN poisoning
Cc: Dmitry Vyukov <dvyukov@google.com> # Help with KASAN
Cc: Paolo Abeni <pabeni@redhat.com> # Reduced batch size
Signed-off-by: Alexander Lobakin <redacted>
---
include/linux/skbuff.h | 2 +
net/core/skbuff.c | 94 ++++++++++++++++++++++++++++++++++++------
2 files changed, 83 insertions(+), 13 deletions(-)
From: Paolo Abeni <pabeni@redhat.com> Date: 2021-02-11 15:29:13
On Thu, 2021-02-11 at 14:28 +0000, Alexander Lobakin wrote:
From: Paolo Abeni <pabeni@redhat.com> on Thu, 11 Feb 2021 11:16:40 +0100 wrote:
quoted
What about changing __napi_alloc_skb() to always use
the __napi_build_skb(), for both kmalloc and page backed skbs? That is,
always doing the 'data' allocation in __napi_alloc_skb() - either via
page_frag or via kmalloc() - and than call __napi_build_skb().
I think that should avoid adding more checks in __alloc_skb() and
should probably reduce the number of conditional used
by __napi_alloc_skb().
I thought of this too. But this will introduce conditional branch
to set or not skb->head_frag. So one branch less in __alloc_skb(),
one branch more here, and we also lose the ability to __alloc_skb()
with decached head.
Just to try to be clear, I mean something alike the following (not even
build tested). In the fast path it has less branches than the current
code - for both kmalloc and page_frag allocation.
---
@@ -506,23 +506,12 @@ struct sk_buff *__napi_alloc_skb(struct napi_struct *napi, unsigned int len,gfp_tgfp_mask){structnapi_alloc_cache*nc;+boolhead_frag,pfmemalloc;structsk_buff*skb;void*data;len+=NET_SKB_PAD+NET_IP_ALIGN;-/* If requested length is either too small or too big,-*weusekmalloc()forskb->headallocation.-*/-if(len<=SKB_WITH_OVERHEAD(1024)||-len>SKB_WITH_OVERHEAD(PAGE_SIZE)||-(gfp_mask&(__GFP_DIRECT_RECLAIM|GFP_DMA))){-skb=__alloc_skb(len,gfp_mask,SKB_ALLOC_RX,NUMA_NO_NODE);-if(!skb)-gotoskb_fail;-gotoskb_success;-}-nc=this_cpu_ptr(&napi_alloc_cache);len+=SKB_DATA_ALIGN(sizeof(structskb_shared_info));len=SKB_DATA_ALIGN(len);
From: Alexander Lobakin <hidden> Date: 2021-02-11 16:33:14
From: Paolo Abeni <pabeni@redhat.com>
Date: Thu, 11 Feb 2021 15:55:04 +0100
quoted hunk
On Thu, 2021-02-11 at 14:28 +0000, Alexander Lobakin wrote:
quoted
From: Paolo Abeni <pabeni@redhat.com> on Thu, 11 Feb 2021 11:16:40 +0100 wrote:
quoted
What about changing __napi_alloc_skb() to always use
the __napi_build_skb(), for both kmalloc and page backed skbs? That is,
always doing the 'data' allocation in __napi_alloc_skb() - either via
page_frag or via kmalloc() - and than call __napi_build_skb().
I think that should avoid adding more checks in __alloc_skb() and
should probably reduce the number of conditional used
by __napi_alloc_skb().
I thought of this too. But this will introduce conditional branch
to set or not skb->head_frag. So one branch less in __alloc_skb(),
one branch more here, and we also lose the ability to __alloc_skb()
with decached head.
Just to try to be clear, I mean something alike the following (not even
build tested). In the fast path it has less branches than the current
code - for both kmalloc and page_frag allocation.
---
@@ -506,23 +506,12 @@ struct sk_buff *__napi_alloc_skb(struct napi_struct *napi, unsigned int len,gfp_tgfp_mask){structnapi_alloc_cache*nc;+boolhead_frag,pfmemalloc;structsk_buff*skb;void*data;len+=NET_SKB_PAD+NET_IP_ALIGN;-/* If requested length is either too small or too big,-*weusekmalloc()forskb->headallocation.-*/-if(len<=SKB_WITH_OVERHEAD(1024)||-len>SKB_WITH_OVERHEAD(PAGE_SIZE)||-(gfp_mask&(__GFP_DIRECT_RECLAIM|GFP_DMA))){-skb=__alloc_skb(len,gfp_mask,SKB_ALLOC_RX,NUMA_NO_NODE);-if(!skb)-gotoskb_fail;-gotoskb_success;-}-nc=this_cpu_ptr(&napi_alloc_cache);len+=SKB_DATA_ALIGN(sizeof(structskb_shared_info));len=SKB_DATA_ALIGN(len);
Sure. I have a separate WIP series that reworks all three *alloc_skb()
functions, as there's a nice room for optimization, especially after
that tiny skbs now fall back to __alloc_skb().
It will likely hit mailing lists after the merge window and next
net-next season, not now. And it's not really connected with NAPI
cache reusing.