sowmini.varadhan at sun.com wrote:
> I spent some time thinking about this one..
>
> The proposal is that we would have something like
>
> # dladm set-linkprop -p en-mii=100M-fh,10M-h link1
>
> which I would venture, would set 100M-fdx, 100M-hdx, 10M-hdx,
> and leave any other existing settings (e.g., 1000M-fdx) unchanged.
>
> But in that world, how do I turn *off* some setting (e.g., 10M-fdx
> and 10M-hdx)?
>
> One (poor, imo) choice is to say that *all* speed-duplex settings must
> be enumerated in the set-linkprop line at all times, and anything
> that isn't present will not be set. This would result in a clumsy,
> bulky command line (I personally would find it tedious to use).
>
> Another choice is to allow
>
> # dladm set-linkprop -p en-mii=100M-fh,no-10M-fh link1
>
> where the "no-" prefix is the "turn off" indicator which can
> be applied before any of the <speed>-<duplex> args passed to en-mii.
>
> But this is not perfect either. In this model, the args to set-linkprop
> are not going to be symmetric with the output of show-linkprop (which
> would only show the speed-duplex settings that are set/settable to 1
> in the current/default/possible configuration.
>
> Thoughts?
>
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.
So, leave the current direct access to MII bits (via en_100_fdx etc.) alone.
-- Garrett
> --Sowmini
>
> _______________________________________________
> brussels-dev mailing list
> brussels-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/brussels-dev
>
