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).

Powered by blists - more mailing lists