[RFC] ethtool semantics

[RFC] ethtool semantics

[Roger Luethi]

What is the correct response if a user passes ethtool speed or duplex
arguments while autoneg is on? Some possible answers are:

a) Yell at the user for doing something stupid.

b) Fail silently (i.e. ignore command).

c) Change advertised value accordingly and initiate new negotiation.

d) Consider "autoneg off" implied, force media accordingly.

The ethtool(8) man page I'm looking at doesn't address that question. The
actual behavior I've seen is b) which is by far my least preferred
solution.

Roger

Re: [RFC] ethtool semantics

[David S. Miller]

On Mon, 7 Jun 2004 23:28:04 +0200
Roger Luethi <rl@hellgate.ch> wrote:

> What is the correct response if a user passes ethtool speed or duplex
> arguments while autoneg is on? Some possible answers are:
> 
> a) Yell at the user for doing something stupid.
> 
> b) Fail silently (i.e. ignore command).
> 
> c) Change advertised value accordingly and initiate new negotiation.
> 
> d) Consider "autoneg off" implied, force media accordingly.
> 
> The ethtool(8) man page I'm looking at doesn't address that question. The
> actual behavior I've seen is b) which is by far my least preferred
> solution.

speed and duplex fields should be silently ignored in this case

Re: [RFC] ethtool semantics

[Marc Herbert]

On Mon, 7 Jun 2004, David S. Miller wrote:

> On Mon, 7 Jun 2004 23:28:04 +0200
> Roger Luethi <rl@hellgate.ch> wrote:
>
> > What is the correct response if a user passes ethtool speed or duplex
> > arguments while autoneg is on? Some possible answers are:
> >
> > a) Yell at the user for doing something stupid.
> >
> > b) Fail silently (i.e. ignore command).
> >
> > c) Change advertised value accordingly and initiate new negotiation.
> >
> > d) Consider "autoneg off" implied, force media accordingly.
> >
> > The ethtool(8) man page I'm looking at doesn't address that question. The
> > actual behavior I've seen is b) which is by far my least preferred
> > solution.

> speed and duplex fields should be silently ignored in this case

I find the c) feature very convenient. For instance it allows reliably
downgrading a link connected to a switch without having to fiddle with
the configuration of the switch, something which is usually (pick your
favourites) non-standard, painful, not authorized, not implemented,
buggy,...

Command line parameters of the bcm5700 driver do implement c) (among
other nifties). Documented in its man page. Command line parameters of
e1000 also allow some control over the autonegociation process, even
if not using c) but a different (and less user-friendly) syntax. See
Documentation/--/e1000.txt. From David's words, I suspect this feature
is simply missing from ethtool.

Finally, silently ignoring user input is not very user-friendly IMHO.
I would much prefer a) to b).

I am aware that my preferences are probably in inverse order of the
amount of work required.



PS: I read netdev but not linux-kernel

Re: [RFC] ethtool semantics

[Roger Luethi]

On Mon, 07 Jun 2004 14:57:23 -0700, David S. Miller wrote:
> On Mon, 7 Jun 2004 23:28:04 +0200
> Roger Luethi <rl@hellgate.ch> wrote:
> 
> > What is the correct response if a user passes ethtool speed or duplex
> > arguments while autoneg is on? Some possible answers are:
> > 
[...]
> speed and duplex fields should be silently ignored in this case

It may not matter much because few people care about forced media these
days. And it is debatable whether trying to guess the users intention
is a good idea (we lack means for users to manipulate autoneg results
via advertisted values but that's no big deal).

However, "silently ignoring" strikes me as a very poor choice, in
stark contrast to Unix/Linux tradition. A user issues a command which
cannot be executed and gets the same response that is used to indicate
success!? What school of user interface design is that? How is that
not confusing users? </rant>

Roger

Re: [RFC] ethtool semantics

[Bill Davidsen]

Roger Luethi wrote:
> On Mon, 07 Jun 2004 14:57:23 -0700, David S. Miller wrote:
> 
>>On Mon, 7 Jun 2004 23:28:04 +0200
>>Roger Luethi <rl@hellgate.ch> wrote:
>>
>>
>>>What is the correct response if a user passes ethtool speed or duplex
>>>arguments while autoneg is on? Some possible answers are:
>>>
> 
> [...]
> 
>>speed and duplex fields should be silently ignored in this case
> 
> 
> It may not matter much because few people care about forced media these
> days. And it is debatable whether trying to guess the users intention
> is a good idea (we lack means for users to manipulate autoneg results
> via advertisted values but that's no big deal).

It does sometimes matter, because even these days we sometimes see a 
case where a brand name switch (like Cisco) and a brand name card 
(Intel, 3COM) negotiate but just don't "work right" later. In those 
cases forcing on both ends or just the NIC end results in a fully 
functional connection.

We usually do this with module parameters, but do use ethtool (or 
mii-tool) on occasion.

> 
> However, "silently ignoring" strikes me as a very poor choice, in
> stark contrast to Unix/Linux tradition. A user issues a command which
> cannot be executed and gets the same response that is used to indicate
> success!? What school of user interface design is that? How is that
> not confusing users? </rant>

Yah.

Seeing this happen while autonegotiation is in progress is a small and 
unlikely window of course!

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: [RFC] ethtool semantics

[Roger Luethi]

On Wed, 09 Jun 2004 17:09:04 -0400, Bill Davidsen wrote:
> cases forcing on both ends or just the NIC end results in a fully 
> functional connection.
> 
> We usually do this with module parameters, but do use ethtool (or 
> mii-tool) on occasion.

<sigh> I just killed the module parameters in my via-rhine development
tree. I suppose you don't use via-rhine!? :-) Nobody complained when
the code was broken for the longest time, and the current design has
all kinds of issues, not the least of which is a distinct lack of sane
semantics for stuff like hotplug, interface renaming, etc.

I'd prefer not to spend my time writing a clean implementation (or fixing
up the current one) of a mechanism that is conceptually obsolete.

> >However, "silently ignoring" strikes me as a very poor choice, in
> >stark contrast to Unix/Linux tradition. A user issues a command which
> >cannot be executed and gets the same response that is used to indicate
> >success!? What school of user interface design is that? How is that
> >not confusing users? </rant>
> 
> Yah.
> 
> Seeing this happen while autonegotiation is in progress is a small and 
> unlikely window of course!

Hmm? It's not about autoneg being in progress, and it's not a race
of any kind. If your NIC comes up with nway autoneg enabled, you must
use ethtool to explicitly turn autoneg off before you can use ethtool
duplex/speed options to force a media mode. However, if you try to force
media with autoneg still enabled, your command will be silently ignored.
It's up to the user to find out that the command failed and why.

Roger

Re: [RFC] ethtool semantics

[David S. Miller]

On Wed, 9 Jun 2004 23:38:50 +0200
Roger Luethi <rl@hellgate.ch> wrote:

> <sigh> I just killed the module parameters in my via-rhine development
> tree.

That is absolutely the correct thing to do, module parameters for
link settings are %100 deprecated, people need to use ethtool for
everything.

Re: [RFC] ethtool semantics

[Marc Herbert]

On Wed, 9 Jun 2004, David S. Miller wrote:

> On Wed, 9 Jun 2004 23:38:50 +0200
> Roger Luethi <rl@hellgate.ch> wrote:
>
> > <sigh> I just killed the module parameters in my via-rhine development
> > tree.
>
> That is absolutely the correct thing to do, module parameters for
> link settings are %100 deprecated, people need to use ethtool for
> everything.

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.


On Tue, 8 Jun 2004, Marc Herbert wrote:

> > On Mon, 7 Jun 2004 23:28:04 +0200
> > Roger Luethi <rl@hellgate.ch> wrote:
> >
> > > What is the correct response if a user passes ethtool speed or duplex
> > > arguments while autoneg is on? Some possible answers are:

> > > c) Change advertised value accordingly and initiate new negotiation.

> I find the c) feature very convenient. For instance it allows reliably
> downgrading a link connected to a switch without having to fiddle with
> the configuration of the switch, something which is usually (pick your
> favourites) non-standard, painful, not authorized, not implemented,
> buggy,...

In case any one wondered: probably the most common motivation for
manually downgrading a link is when the cabling is found to be not
"good enough" for the max common speed of the two transceivers.
(see "Gigabit Ethernet - Rich Seifert, section 8.2.3")

See also: "Running 1000BASE-T: Gigabit Ethernet over Copper"
  http://www.10gea.org/GEA_copper_0999_rev-wp.pdf
 "The 1000BASE-T Task Force and the cabling companies estimate that
 less than 10 percent of the installed base of Category 5 cable was
 improperly installed,"

I find "less than 10 percent" not so negligible.

Re: [RFC] ethtool semantics

[Tim Hockin]

On Mon, Jun 14, 2004 at 03:11:15PM +0200, Marc Herbert wrote:
> > That is absolutely the correct thing to do, module parameters for
> > link settings are %100 deprecated, people need to use ethtool for
> > everything.
> 
> 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

Re: [RFC] ethtool semantics

[Marc Herbert]

On Mon, 14 Jun 2004, Tim Hockin wrote:

> > 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.

Re: [RFC] ethtool semantics

[Roger Luethi]

On Mon, 14 Jun 2004 10:01:38 -0700, Tim Hockin wrote:
> On Mon, Jun 14, 2004 at 03:11:15PM +0200, Marc Herbert wrote:
> > > That is absolutely the correct thing to do, module parameters for
> > > link settings are %100 deprecated, people need to use ethtool for
> > > everything.
> > 
> > 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

My first thought was if a command contains speed/duplex settings
and autoneg is on, manipulate advertised value; if autoneg is off,
force mode. That's not possible due to the way ethtool interacts with
the kernel: It doesn't request a change in a specific field. Instead,
ethtool reads all fields, flips the values it wants to have changed,
then issues a set request for everything (speed, duplex, autoneg,
etc.). In other words: speed/duplex fields are set for every call.

One way out would be to have an explicit third option, say autoneg mask.

That would give:
autoneg on + speed/duplex -> error (only userspace/ethtool can do this!)
autoneg off + speed/duplex -> force mode (driver)
autoneg mask + speed/duplex -> change advertised value (driver)

Many drivers would only support one of these two methods (force mode
presumably), so we'd have to either throw an error if an unsupported
method is requested, or print a notice and use the supported method to
force the requested mode.

Roger