Re: [PATCH v2 net-next] net/mlx5e: Report rx_discards_phy via rx_fifo_errors

[Saeed Mahameed <saeed@kernel.org>]

On 15 Nov 11:24, Jakub Kicinski wrote:
>On Fri, 15 Nov 2024 00:01:50 -0800 Saeed Mahameed wrote:
>> not rx_missed_errors please, it is exclusive for software lack of buffers.
>>
>> Please have a look at thtool_eth_XXX_stats IEEE ethnl_stats, if you need to
>> extend, this is the place.
>>
>> RFC2863[1] defines this type of discards as ifInDiscards. So let's add
>> it to ehttool std stats. mlx5 reports most of them already to driver custom
>> ethtool -S
>
>We can, but honestly I'd just make sure they are counted in rx_dropped

rx_dropped: Number of packets received but not processed,
  *   e.g. due to lack of resources or unsupported protocol.
  *   For hardware interfaces this counter may include packets discarded
  *   due to L2 address filtering but should not include packets dropped
                                  ^^^^^^^^^^^^^^
  *   by the device due to buffer exhaustion which are counted separately in
                           ^^^^^^^^^^^^^^^^^
  *   @rx_missed_errors (since procfs folds those two counters together).
      ^^^^^^^^^^^^^^^^^

I think we should use rx_fifo_errors for this and update documentation:

rx_missed_errors --> host buffers
rx_fifo_errors   --> device buffers
rx_dropped       --> unsupported portocols, filter drops, link down, etc..

rx_dropped doesn't reflect a performance issue, but a configuration mishap
"lack of resources" should be removed from the doc or improved
since I believe it meant "allocation failure of resources" such as skbs,
which is the common use case.

>and leave the detailed breakdown in ethtool -S. The value of the common
>stats kicks in when we have multiple NICs with reasonably similar
>interpretations. Hopefully for missed we do have that interpretation.
>Anything further down in the pipeline will be device specific.
>Or at least I haven't figured out sufficient commonalities among
>the devices I deal with in production..
>