linux-kernel - Re: [PATCH net-next 4/4] net: dsa: felix: drop oversized frames with tc-taprio instead of hanging the port

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]

Message-ID: <20220627194030.uyaygut2n2sjywni@skbuf>
Date:   Mon, 27 Jun 2022 19:40:31 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Michael Walle <michael@...le.cc>,
        Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        Maxim Kochetkov <fido_max@...ox.ru>,
        Colin Foster <colin.foster@...advantage.com>,
        Richie Pearn <richard.pearn@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 4/4] net: dsa: felix: drop oversized frames with
 tc-taprio instead of hanging the port

On Mon, Jun 27, 2022 at 11:46:44AM -0700, Jakub Kicinski wrote:
> On Sun, 26 Jun 2022 15:05:05 +0300 Vladimir Oltean wrote:
> > When a frame is dropped due to a queue system oversize condition, the
> > counter that increments is the generic "drop_tail" in ethtool -S, even
> > if this isn't a tail drop as the rest (i.e. the controlling watermarks
> > don't count these frames, as can be seen in "devlink sb occupancy show
> > pci/0000:00:00.5 sb 0"). So the hardware counter is unspecific
> > regarding the drop reason.
> 
> I had mixed feelings about the stats, as I usually do, but I don't
> recall if I sent that email. Are you at least counting the drop_tail
> into one of the standard tx error / drop stats so admins will notice?

Sorry for being unclear, fact is, I had even forgot this small detail
between testing and writing the commit message...

The switch, being a switch, will not 'drop' the packet per se, it will
still try to forward it towards the ports it can. It will only drop it
and record it as such if it couldn't forward it towards any port (i.e.
if we're in a 2-port bridge and there isn't any learned FDB entry, it
will still flood it towards the CPU).
Because of that, the "drop_tail" counter is incremented on the _ingress_
port. Good luck counting that into a tx_errors counter :)