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