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