netdev - Re: [net-next PATCH 05/15] net: sched: a dflt qdisc may be used with per cpu stats

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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