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:   Fri, 11 Sep 2020 19:54:11 -0700
From:   Florian Fainelli <>
To:     Jakub Kicinski <>,
        Vladimir Oltean <>
Subject: Re: [PATCH net-next v2 0/8] ethtool: add pause frame stats

On 9/11/2020 5:42 PM, Jakub Kicinski wrote:
> On Sat, 12 Sep 2020 03:15:42 +0300 Vladimir Oltean wrote:
>> On Fri, Sep 11, 2020 at 05:07:24PM -0700, Jakub Kicinski wrote:
>>> On Sat, 12 Sep 2020 02:49:32 +0300 Vladimir Oltean wrote:
>>>> On Fri, Sep 11, 2020 at 04:28:45PM -0700, Jakub Kicinski wrote:
>>>>> Hi!
>>>>> This is the first (small) series which exposes some stats via
>>>>> the corresponding ethtool interface. Here (thanks to the
>>>>> excitability of netlink) we expose pause frame stats via
>>>>> the same interfaces as ethtool -a / -A.
>>>>> In particular the following stats from the standard:
>>>>>   - aPAUSEMACCtrlFramesTransmitted
>>>>>   - aPAUSEMACCtrlFramesReceived
>>>>> 4 real drivers are converted, hopefully the semantics match
>>>>> the standard.
>>>>> v2:
>>>>>   - netdevsim: add missing static
>>>>>   - bnxt: fix sparse warning
>>>>>   - mlx5: address Saeed's comments
>>>> DSA used to override the "ethtool -S" callback of the host port, and
>>>> append its own CPU port counters to that.
>>>> So you could actually see pause frames transmitted by the host port and
>>>> received by the switch's CPU port:
>>>> # ethtool -S eno2 | grep pause
>>>> MAC rx valid pause frames: 1339603152
>>>> MAC tx valid pause frames: 0
>>>> p04_rx_pause: 0
>>>> p04_tx_pause: 1339603152
>>>> With this new command what's the plan?
>>> Sounds like something for DSA folks to decide :)
>>> What does ethtool -A $cpu_port control?
>>> The stats should match what the interface controls.
>> Error: $cpu_port: undefined variable.
>> With DSA switches, the CPU port is a physical Ethernet port mostly like
>> any other, except that its orientation is inwards towards the system
>> rather than outwards. So there is no network interface registered for
>> it, since I/O from the network stack would have to literally loop back
>> into the system to fulfill the request of sending a packet to that
>> interface.
> Sorry, perhaps I should have said $MAC, but that kind of in itself
> answers the question.
>> The ethtool -S framework was nice because you could append to the
>> counters of the master interface while not losing them.
>> As for "ethtool -A", those parameters are fixed as part of the
>> fixed-link device tree node corresponding to the CPU port.
> I think I'm missing the problem you're trying to describe.
> Are you making a general comment / argument on ethtool stats?
> Pause stats are symmetrical - as can be seen in your quote
> what's RX for the CPU is TX for the switch, and vice versa.
> Since ethtool -A $cpu_mac controls whether CPU netdev generates
> and accepts pause frames, correspondingly the direction and meaning
> of pause statistics on that interface is well defined.
> You can still append your custom CPU port stats to ethtool -S or
> debugfs or whatnot, but those are only useful for validating that
> the configuration of the CPU port is not completely broken. Otherwise
> the counters are symmetrical. A day-to-day user of the device doesn't
> need to see both of them.

It would be a lot easier to append the stats if there was not an 
additional ndo introduce to fetch the pause statistics because DSA 
overlay ndo on a function by function basis. Alternatively we should 
consider ethtool netlink operations over a devlink port at some point so 
we can get rid of the ugly ndo and ethtool_ops overlay that DSA does.

Can we consider using get_ethtool_stats and ETH_SS_PAUSE_STATS as a 
stringset identifier? That way there is a single point within driver to 
fetch stats.

Powered by blists - more mailing lists