netdev - Re: [patch net-next 5/5] mlxsw: spectrum: qdiscs: Support stats for PRIO qdisc

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20180112003230.2f00e36a@laptop>
Date:   Fri, 12 Jan 2018 00:32:30 -0800
From:   Jakub Kicinski <kubakici@...pl>
To:     Yuval Mintz <yuvalm@...lanox.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Nogah Frankel <nogahf@...lanox.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "Ido Schimmel" <idosch@...lanox.com>, mlxsw <mlxsw@...lanox.com>,
        "jhs@...atatu.com" <jhs@...atatu.com>,
        "xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>
Subject: Re: [patch net-next 5/5] mlxsw: spectrum: qdiscs: Support stats for
 PRIO qdisc

On Fri, 12 Jan 2018 00:39:26 +0000 Yuval Mintz wrote:
> > Hm.  You you need this just because you didn't add the backlog
> > pointer to destroy?  AFAIK on destroy we are free to reset stats as
> > well, thus simplifying your driver...  Let me know if I
> > misunderstand.  
> 
> This is meant exactly for the scenario where qdisc didn't get
> destroyed yet is no longer offloaded; E.g., if number of bands
> increased beyond What we can offload. So we can't reset the
> statistics in this case. [Although I might be the one to
> misunderstand you, as the 'not destroyed' was explicitly mentioned
> twice above]

I was trying to take some liberty with handling of destroy but your
approach may actually end up being simpler.  I will withdraw my series
for now and reuse your new callback once this series lands.

Do you have any objections to changing RED to behave more like prio
(and other qdiscs) in principle?