[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57BDDE51.2050106@gmail.com>
Date: Wed, 24 Aug 2016 10:50:09 -0700
From: John Fastabend <john.fastabend@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: jhs@...atatu.com, davem@...emloft.net, brouer@...hat.com,
xiyou.wangcong@...il.com, alexei.starovoitov@...il.com,
john.r.fastabend@...el.com, netdev@...r.kernel.org
Subject: Re: [net-next PATCH 05/15] net: sched: a dflt qdisc may be used with
per cpu stats
On 16-08-24 10:26 AM, Eric Dumazet wrote:
> On Wed, 2016-08-24 at 10:13 -0700, John Fastabend wrote:
>
>>>
>>
>> I could fully allocate it in qdisc_alloc() but we don't know if the
>> qdisc needs per cpu data structures until after the init call
>
> Should not we have a flag to advertise the need of per spu stats on
> qdisc ?
>
> This is not clear why ->init() can know this, and not its caller.
>
sure we could be a static_flags field in the ops structure. What do
you think about doing that?
We would still need some flags to be set at init though like the bypass
bit it looks like some qdiscs set that based on user input.
>> . So it
>> would sit unused in those cases if done from qdisc_alloc(). It seems
>> best to me at least to just avoid the allocation in qdisc_alloc() and
>> do it after init like I did here.
>>
>> Perhaps it would be nice to pull these into a function call
>> post_init_qdisc_alloc() that does all this allocation?
>>
>> .John
>>
>
>
Powered by blists - more mailing lists