Re: [RFC PATCH net-next v2 09/17] ethtool: implement GET_DRVINFO message

From: Michal Kubecek <mkubecek@suse.cz>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jiri Pirko <jiri@resnulli.us>, David Miller <davem@davemloft.net>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Roopa Prabhu <roopa@cumulusnetworks.com>,
	Jakub Kicinski <kubakici@wp.pl>,
	"John W. Linville" <linville@tuxdriver.com>
Subject: Re: [RFC PATCH net-next v2 09/17] ethtool: implement GET_DRVINFO message
Date: Mon, 30 Jul 2018 18:47:14 +0200	[thread overview]
Message-ID: <20180730164714.lqf5codtzxigsufe@unicorn.suse.cz> (raw)
In-Reply-To: <20180730154803.GB2983@lunn.ch>

On Mon, Jul 30, 2018 at 05:48:03PM +0200, Andrew Lunn wrote:
> 
> 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.

Thank you for the explanation. What I have in mind is that there are two
different types of userspace applications: one shot and running long
term. It can be seen in my series in the way e.g. link modes are
handled. There are two formats in which a bitset can be passed: verbose
(list of bits with names) or compact (just bitmaps). For one shot
queries (e.g. "ethtool eth0") it's easier to use verbose format so that
you get names with bit values in one package. But for long running
applications processing many messages ("ethtool --monitor" or config
management daemons), it's more practical to load the names once and pass
only data with each notification or response.

I suppose in the scenarios you mentioned the driver would be able to
trigger a notification whenever the list changes so that userspace
application could reload the string set.

Michal Kubecek