[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <08108451-6f6a-6e89-4d2d-52e064b1342c@gmail.com>
Date: Fri, 11 Sep 2020 19:54:11 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Jakub Kicinski <kuba@...nel.org>,
Vladimir Oltean <olteanv@...il.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org, mkubecek@...e.cz,
michael.chan@...adcom.com, tariqt@...dia.com, saeedm@...dia.com,
alexander.duyck@...il.com, andrew@...n.ch
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:
>>>>> - 30.3.4.2 aPAUSEMACCtrlFramesTransmitted
>>>>> - 30.3.4.3 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.
--
Florian
Powered by blists - more mailing lists