netdev - Re: [PATCH net-next 2/2] net: enetc: count the tc-taprio window drops

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, 11 May 2022 16:36:55 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        Michael Walle <michael@...le.cc>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        Po Liu <po.liu@....com>
Subject: Re: [PATCH net-next 2/2] net: enetc: count the tc-taprio window
 drops

On Wed, 11 May 2022 23:17:46 +0000 Vladimir Oltean wrote:
> On Wed, May 11, 2022 at 04:13:46PM -0700, Jakub Kicinski wrote:
> > On Wed, 11 May 2022 22:57:46 +0000 Vladimir Oltean wrote:  
> > > The only entry that is a counter in the Scheduled Traffic MIB is TransmissionOverrun,
> > > but that isn't what this is. Instead, this would be a TransmissionOverrunAvoidedByDropping,
> > > for which there appears to be no standardization.  
> > 
> > TransmissionOversized? There's no standardization in terms of IEEE but
> > the semantics seem pretty clear right? The packet is longer than the
> > entire window so it can never go out?  
> 
> Yes, so what are you saying? Become the ad-hoc standards body for
> scheduled traffic?

We can argue semantics but there doesn't need to be a "standards body"
to add a structured stat in ethtool [1]. When next gen of enetc comes
out you'll likely try to use the same stat name or reuse the entire
driver. So you are already defining uAPI for your users, it's only 
a question of scope at which the uAPI is defined.

What I'm not sure of is what to attach that statistic to. You have it
per ring and we famously don't have per ring APIs, so whatever, let 
me apply as is and move on :)

[1] Coincidentally I plan to add a "real link loss" statistic there
because AFAICR IEEE doesn't have a stat for it, and carrier_changes
count software events so it's meaningless to teams trying to track
cable issues.