[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180730154803.GB2983@lunn.ch>
Date: Mon, 30 Jul 2018 17:48:03 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Michal Kubecek <mkubecek@...e.cz>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Jiri Pirko <jiri@...nulli.us>,
David Miller <davem@...emloft.net>,
Florian Fainelli <f.fainelli@...il.com>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
Jakub Kicinski <kubakici@...pl>,
"John W. Linville" <linville@...driver.com>
Subject: Re: [RFC PATCH net-next v2 09/17] ethtool: implement GET_DRVINFO
message
> This is interesting. It would mean current (ioctl) ethtool approach with
> string set may not work correctly either.
Hi Michal
For the statistics, it is a bit of a corner case. One of the Ethernet
switches in DSA can have two different PHYs linked to one MAC. One PHY
is built in, the second is connected via a SERDES interface. Which
every gets link first is used. However, the SERDES interface has
additional statistics counters. So if the SERDES is in use, we return
more statistics. If somebody was to plug in the cable at just the
wrong/right time, the count of statistics could be different to the
number of statistics.
Another corner case i can think of. Some drivers return statistics per
queue. And there is an ioctl to change the number of queues....
I could also imaging tests being similar. There are more loopback
tests you can do with a SERDES which you cannot do with a built in
PHY. But so far, i've not seen anything like that.
Andrew
Powered by blists - more mailing lists