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
| ||
|
Date: Tue, 19 Jul 2022 13:57:58 -0700 From: Jakub Kicinski <kuba@...nel.org> To: Gal Pressman <gal@...dia.com> Cc: Saeed Mahameed <saeed@...nel.org>, "David S. Miller" <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>, Saeed Mahameed <saeedm@...dia.com>, netdev@...r.kernel.org, Tariq Toukan <tariqt@...dia.com> Subject: Re: [net-next 03/14] net/mlx5e: Expose rx_oversize_pkts_buffer counter On Tue, 19 Jul 2022 14:13:39 +0300 Gal Pressman wrote: > > Is it counted towards any of the existing stats as well? It needs > > to end up in struct rtnl_link_stats64::rx_length_errors somehow. > > Probably makes sense to count it in rx_over_errors: > * The recommended interpretation for high speed interfaces is - > * number of packets dropped because they did not fit into buffers > * provided by the host, e.g. packets larger than MTU or next buffer > * in the ring was not available for a scatter transfer. I think I wrote that based on what 3c509 or some similarly ancient NIC was doing. Since then I've seen too many drivers using it for queue exhaustion to hope for the interpretation to take over. But yes, not the worst choice, if you prefer that works. > It doesn't fit the rx_length_errors (802.3) as these packets are not > dropped on the MAC. > Will change. I don't think rx_length_errors says it's MAC drops anywhere. I put the list of IEEE eth counters there as an example. rx length errors is a catch all for length errors.
Powered by blists - more mailing lists