Peter Memishian wrote:
> > In my opinion, as crummy as the current model is, it is the one that
> > administrators have learned to live with. I don't think it is worth
> > changing.
> >
> > In fact, I think we ought to be discouraging direct access to these
> > auto-negotiation parameters. The reality is that administrators should
> > never be touching them -- everything should be left enabled --
> > especially in the era of modern full-duplex and gigabit (and 10 gigabit)
> > links.
>
> I asked Sowmini to look into this because the existing model makes the
> dladm show-linkprop output unpleasant to work with. As you say, folks
> should not be touching these -- so it'd be better if they weren't so
> prominent. Yes, it's a small thing; I make no apologies for being a
> picky bastard ;-)
>
>
So how about instead we figure out a way to suppress display of these
properties by default? (I'd be OK with an option that only showed them
if they were set to something other than their "default" option, which
should be to enable everything the hardware can do.)
I'd also be willing to entertain a PSARC case to simplify the management
of these by reducing the flexibility. For example, generally folks
that use these things only do one of two things:
1) enable full support
2) force a setting to work around failures in autonegotiation
I've never heard of a case, outside of "debugging" and testing (e.g.
NICDRV) where the properties were used in any other fashion. So one
could for example define a single "linkmode" property that specified the
speed and duplex setting. So the available link modes would be:
"auto" -- full autonegotiation for everything the chip supports
"10g" -- force 10gig (full duplex implied)
"1000fdx" -- force 1000 full duplex
"1000hdx" -- force 1000 half duplex
"100fdx" -- force 100 full duplex
"100hdx" -- force 100 half duplex
"10fdx" -- force 10 full duplex
"10hdx" -- force 10 half duplex
Now that said, I'll also note that the 802.3 spec prohibits use of full
duplex unless autonegotiation is used. We have lots of folks that
"force" this in drivers, which puts them out of spec. IMO, "forcing" a
setting with full duplex is just plain wrong. But one could imagine a
"forced" mode which is really just using autonegotiation with just a
single mode advertised. One way to express this would be to have
additional values, so you have:
"auto"
"10g-full"
"1000-full"
"1000-half"
"1000-forced"
"100-full"
"100-half"
"100-forced"
"10-full"
"10-half"
"10-forced"
In this case the "forced" modes would imply half duplex operation.
While this option is more elegant and would ensure conformance to the
standard, it does have the negative feature of breaking compatibility
with any existing non-compliant installations. (And there are *many*
sites that foolishly continue to run forced-full-duplex installations,
even though such installations never work out of the box with existing
hardware, always require manual settings, and are non-compliant with the
actual 802.3 specifications.)
I'd actually go so far as to suggest that the "10g" and "1000" options
for forcing be removed from the list, since I believe that sites which
run at forced settings only do so for 100 Mbps. So the new list would
look like:
"auto"
"100fdx"
"100hdx"
"10fdx"
"10hdx"
This would eliminate most of the other settings. (The only problem I
see with this is that QA needs the ability to force a mode for other
reasons.)
Another option would be to emit a complaint on usage that forcing any
mode is highly unrecommended.
-- Garrett
