linux-kernel - Re: [PATCH net-next v1 1/1] net: dsa: microchip: add stats64 support for ksz8 series of switches

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: <20221208055512.GE19179@pengutronix.de>
Date:   Thu, 8 Dec 2022 06:55:12 +0100
From:   Oleksij Rempel <o.rempel@...gutronix.de>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Woojung Huh <woojung.huh@...rochip.com>,
        Andrew Lunn <andrew@...n.ch>, Arun.Ramadoss@...rochip.com,
        Florian Fainelli <f.fainelli@...il.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        UNGLinuxDriver@...rochip.com, Eric Dumazet <edumazet@...gle.com>,
        Vladimir Oltean <olteanv@...il.com>, kernel@...gutronix.de,
        Vivien Didelot <vivien.didelot@...il.com>,
        Paolo Abeni <pabeni@...hat.com>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next v1 1/1] net: dsa: microchip: add stats64 support
 for ksz8 series of switches

On Wed, Dec 07, 2022 at 03:48:26PM -0800, Jakub Kicinski wrote:
> On Wed, 7 Dec 2022 07:16:30 +0100 Oleksij Rempel wrote:
> > > FWIW for normal netdevs / NICs the rtnl_link_stat pkts do not include
> > > pause frames, normally. Otherwise one can't maintain those stats in SW
> > > (and per-ring stats, if any, don't add up to the full link stats).
> > > But if you have a good reason to do this - I won't nack..  
> > 
> > Pause frames are accounted by rx/tx_bytes by HW. Since pause frames may
> > have different size, it is not possible to correct byte counters, so I
> > need to add them to the packet counters.
> 
> I have embarrassed myself with my lack of understanding of pause frames
> before but nonetheless - are you sure?  I thought they are always 64B.
> Quick look at the standard seems to agree:
> 
>  31C.3.1 Receive state diagram (INITIATE MAC CONTROL FUNCTION) for
>          EXTENSION operation
> 
> shows a 64 octet frame.
> 
> Sending long pause frames seems self-defeating as we presumably want
> the receiver to react ASAP.

I tested it by sending correct and malformed pause frames manually with
mausezahn. Since it is possible to send and receive pause frames
manually, it is good to count all bytes in use, otherwise we may have
bogus or malicious stealth traffic without possibility to measure it.

Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |