netdev - Re: [PATCH net-next] net: tighten the definition of interface statistics

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 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:   Thu, 3 Sep 2020 14:15:26 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Edwin Peer <edwin.peer@...adcom.com>,
        "David S . Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Julian Wiedmann <jwi@...ux.ibm.com>, andrew@...n.ch,
        mkubecek@...e.cz, dsahern@...il.com,
        Michael Chan <michael.chan@...adcom.com>, saeedm@...lanox.com,
        rmk+kernel@...linux.org.uk
Subject: Re: [PATCH net-next] net: tighten the definition of interface
 statistics

On Thu, 3 Sep 2020 13:48:39 -0700 Florian Fainelli wrote:
> >>> + * @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?  
> > 
> > Good point, no FCS is probably a reasonable expectation.
> > 
> > I'm not sure what to say about pad. I'm tempted to also mention that
> > for tx we shouldn't count pad, no? (IOW Ethernet Frame - FCS - pad)  
> 
> It depends I would say, if the driver needed to add padding in order to 
> get the frame to be transmitted because the Ethernet MAC cannot pad 
> automatically then it would seem natural to count the added padding.

Ack, I was actually hoping "modern" devices don't need this, but I was
wrong :S Looks like bnxt is padding. And Intel devices pad on RX, which
NFP used to do as well, until I removed it. Any idea why do people do
this?

> If you implement BQL that is what you will be reporting because that how 
> much travels on the wire. What do you think?

No strong preference. I'm not very concerned about BQL, it doesn't
account for other "realities" of wire transmission anyway. And I
thought it would be nice for interface stats to match Qdisc stats.
Plus feels strange putting burden on devices which do things "right".

But unless we count pad on TX we'd have an asymmetry where we expect
pad on RX but not TX. So I think you're right. Let's suggest to count
pad both ways (for Ethernet, at least).