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
> > > > Date:
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 wh
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,
> n
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, an
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 gene
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
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 stor
13 matches
Mail list logo
