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