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  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]
Date:   Thu, 3 Sep 2020 09:29:22 -0700
From:   Edwin Peer <>
To:     Jakub Kicinski <>
Cc:     "David S . Miller" <>,
        netdev <>,
        Julian Wiedmann <>,,,,,
        Michael Chan <>,,
Subject: Re: [PATCH net-next] net: tighten the definition of interface statistics

On Wed, Sep 2, 2020 at 7:03 PM Jakub Kicinski <> wrote:

> +Drivers should report all statistics which have a matching member in
> +:c:type:`struct rtnl_link_stats64 <rtnl_link_stats64>` exclusively
> +via `.ndo_get_stats64`. Reporting such standard stats via ethtool
> +or debugfs will not be accepted.

Should existing drivers that currently duplicate standard stats in the
ethtool list be revised also?

> + * @rx_packets: Number of good packets received by the interface.
> + *   For hardware interfaces counts all good packets seen by the host,
> + *   including packets which host had to drop at various stages of processing
> + *   (even in the driver).

This is perhaps a bit ambiguous. I think you mean to say packets received from
the device, but I could also interpret the above to mean received by the device
if 'host' is read to be the whole physical machine (ie. including NIC hardware)
instead of the part that is apart from the NIC from the NIC's perspective.

> + * @rx_bytes: Number of good incoming bytes, corresponding to @rx_packets.
> + * @tx_bytes: Number of good incoming bytes, corresponding to @tx_packets.

Including or excluding FCS?

> + *   For Ethernet devices this counter may be equivalent to:
> + *
> + *    - aMulticastFramesReceivedOK

You mention the IEEE standard in your commit message, but I don't think this
document properly cites what you are referring to here? It might be an idea to
say "IEEE aMulticastFramesReceivedOK" here and provide an
appropriate citation reference at the end, or perhaps a link.

Edwin Peer

Powered by blists - more mailing lists