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, Jan 13, 2021 at 6:03 PM Jakub Kicinski wrote:
>
> 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
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
> > > >
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: Tue, 12 Jan 2021 09:54:04 +
> > >
> > > > Without wishing to weigh in on
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
On Tue, Jan 12, 2021 at 7:26 PM Alexander Lobakin wrote:
>
> 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.
>
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,
>
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,
not saving memory.
Real GRO (TCP in most cases) will consume one skb,
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 a cache to bulk flush "consumed" skbs, although
> kmem_cache_free() is
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
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
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_alloc().
> On the other hand, we have percpu napi_alloc_cache to
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
14 matches
Mail list logo