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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 19 Jul 2022 13:57:58 -0700
From:   Jakub Kicinski <>
To:     Gal Pressman <>
Cc:     Saeed Mahameed <>,
        "David S. Miller" <>,
        Paolo Abeni <>,
        Eric Dumazet <>,
        Saeed Mahameed <>,,
        Tariq Toukan <>
Subject: Re: [net-next 03/14] net/mlx5e: Expose rx_oversize_pkts_buffer

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