[PATCH net-next 0/5] skbuff: introduce skbuff_heads bulking and reusing

2021-01-11 Thread Alexander Lobakin
Inspired by cpu_map_kthread_run() and _kfree_skb_defer() logics. 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

Re: [PATCH net-next 0/5] skbuff: introduce skbuff_heads bulking and reusing

2021-01-12 Thread Alexander Lobakin
From: Eric Dumazet Date: Tue, 12 Jan 2021 13:32:56 +0100 > On Tue, Jan 12, 2021 at 11:56 AM Alexander Lobakin wrote: >> > >> >> Ah, I should've mentioned that I use UDP GRO Fraglists, so these >> numbers are for GRO. >> > > Right, this suggests UDP GRO fraglist is a pathological case of GRO, > n

Re: [PATCH net-next 0/5] skbuff: introduce skbuff_heads bulking and reusing

2021-01-12 Thread Jakub Kicinski
On Tue, 12 Jan 2021 13:23:16 +0100 Eric Dumazet wrote: > On Tue, Jan 12, 2021 at 12:08 PM Alexander Lobakin wrote: > > > > From: Edward Cree > > Date: Tue, 12 Jan 2021 09:54:04 + > > > > > Without wishing to weigh in on whether this caching is a good idea... > > > > Well, we already have

Re: [PATCH net-next 0/5] skbuff: introduce skbuff_heads bulking and reusing

2021-01-13 Thread Jakub Kicinski
On Wed, 13 Jan 2021 05:46:05 +0100 Eric Dumazet wrote: > On Wed, Jan 13, 2021 at 2:02 AM Jakub Kicinski wrote: > > > > On Tue, 12 Jan 2021 13:23:16 +0100 Eric Dumazet wrote: > > > On Tue, Jan 12, 2021 at 12:08 PM Alexander Lobakin > > > wrote: > > > > > > > > From: Edward Cree > > > > Date:

Re: [PATCH net-next 0/5] skbuff: introduce skbuff_heads bulking and reusing

2021-01-13 Thread Jakub Kicinski
On Wed, 13 Jan 2021 18:15:20 +0100 Eric Dumazet wrote: > > IDK much about MM, but we already have a kmem_cache for skbs and now > > we're building a cache on top of a cache. Shouldn't MM take care of > > providing a per-CPU BH-only lockless cache? > > I think part of the improvement comes from

Re: [PATCH net-next 0/5] skbuff: introduce skbuff_heads bulking and reusing

2021-01-12 Thread Edward Cree
Without wishing to weigh in on whether this caching is a good idea... Wouldn't it be simpler, rather than having two separate "alloc" and "flush" caches, to have a single larger cache, such that whenever it becomes full we bulk flush the top half, and when it's empty we bulk alloc the bottom hal

Re: [PATCH net-next 0/5] skbuff: introduce skbuff_heads bulking and reusing

2021-01-12 Thread Alexander Lobakin
From: Eric Dumazet Date: Tue, 12 Jan 2021 09:20:39 +0100 > On Mon, Jan 11, 2021 at 7:27 PM Alexander Lobakin wrote: >> >> Inspired by cpu_map_kthread_run() and _kfree_skb_defer() logics. >> >> Currently, all sorts of skb allocation always do allocate >> skbuff_heads one by one via kmem_cache_all

Re: [PATCH net-next 0/5] skbuff: introduce skbuff_heads bulking and reusing

2021-01-12 Thread Alexander Lobakin
From: Edward Cree Date: Tue, 12 Jan 2021 09:54:04 + > Without wishing to weigh in on whether this caching is a good idea... Well, we already have a cache to bulk flush "consumed" skbs, although kmem_cache_free() is generally lighter than kmem_cache_alloc(), and a page frag cache to allocate