Re: [RFC] ethtool semantics

On Mon, 14 Jun 2004, Tim Hockin wrote:

quoted

This is precisely the reason why I am concerned about having "rich"
ethtool semantics. A unified, standard interface is great,... as long
it does not leave behind some features, like setting the advertised
values in autoneg. As a user of these features, I hope driver
developers will NOT remove those module_param features that cannot
migrated to ethtool.

So propose a sane semantic that handles all three cases:
* autoneg on
* autoneg off
* autoneg on but limited

Looking at the examples I mentioned earlier in the thread, one can
draw the following two simple solutions:

	  1. "Max speed advertised" solution

		autoneg |         on            off
	  speed         |
	  --------------|-----------------------------
			|
	  <empty>       | advertise all      force  10
	  10            | adv. 10            force  10
	  100           | adv. 10|100        frc.  100
	  1000          | adv. 10|100|1000   frc. 1000


	  2. "Fixed speed advertised" solution

		autoneg |         on            off
	  speed         |
	  --------------|-----------------------------
			|
	  <empty>       | advertise all      force  10
	  10            | adv.   10          force  10
	  100           | adv.  100          frc.  100
	  1000          | adv. 1000          frc. 1000


You can easily figure out similar and shorter tables for half/full
duplex (considering that duplex > half).

A 3rd solution which kind of avoids the dilemma between 1. and 2. is
to give the user full control on advertised bits, as does (did?) the
e1000 driver and its "AutoNeg" module_param. This third solution is
often less user friendly and probably not very useful. And it would
require a new argument to ethtool, whereas the first two solutions do
not.

If given the choice, I would vote for solution 1., but it probably
does not make much difference with solution number 2 in practice.

Auto negociation of flow control is unfortunately more complex, as you
can see in this discussion with Rich Seifert in
comp.dcom.lans.ethernet for those interested
 http://groups.google.com/groups?threadm=87hdvnd0x3.fsf%40free.fr
But I believe flow control issues do not have any influence on the
above, so... first things first: no need to dive into this at this
point.

Obviously this message ignores legacy code, hardware bugs and others
"small matters of implementation". I suspect Roger Luethi has both a
knowledge of the related code and an opinion on this issue.