sowmini.varadhan at sun.com wrote:
> On (06/18/07 11:35), Darren.Reed at Sun.COM wrote:
>
>> A link speed of "1000" is meaningless, plus it does not seem
>> to scale down to modem speed. Either report the full number
>> (10000000, 10000000000) or abbreviate it meaingfullly:
>> 10M, 10G, etc - the default output from "zfs list" is an
>> example of how this can be done:
>>
>
> right, that was just tentative output. It should be abbreviated by the
> appropriate {M,G,..} clarifications as you suggest.
>
The very idea of directly setting the link-speed and link-duplex is one
that I'm uncomfortable with. This hides important details, such as
whether the mode is forced, or is it an 802.3u negotiated speed? It
also removes quite a bit of control. For example, it may be worthwhile
to support the idea of autonegotiation, but disallow certain
configurations.
I hate the fact that folks feel the need to regularly force these link
parameters, but that's a different problem. I do think that as long as
we are offering control, it needs to be full control ... i.e. by
directly allowing one to configure the MII anar bits. (via
adv_cap_100fdx, etc.)
Please stick with the ieee802.3(5) controls, in other words.
>
>> As for what to display for "possible", I don't think that
>> this is meaningful here. I would rather see the default
>> output just be "LINK", "PROPERTY", "VALUE" and "DEFAULT".
>>
>
> unfortunately we already follow the above convention (printing
> POSSIBLE) for wifi links.. so unless we want to break the trend, we
> are stuck with reporting possible. I personally also feel ther eis some
> use in printing possible, as this gives a hint of input range.
>
>
>> Additionally, what are you reporting at the MTU here?
>> The network layer MTU or the link layer MTU?
>>
>
> The mtu reported here is the same as that reported in 'ifconfig -a',
> i.e., the link-layer mtu.
>
Err... not quite. 1500 is the MTU provided to IP, but it does not
include the link layer overhead. (I.e. for ethernet it is somewhat
larger, to allow for a 14 byte header, 4 byte FCS, and optional 4 byte
VLAN tag.)
>
>> How does dladm see itself working with NICs that have
>> pluggable MAUs? For example, if I have a NIC that has
>> a fibre GBIC in it for the MAU but I replace that GBIC
>> with a copper MAU, how would dladm cope with that?
>> Do I need to plumb/unplumb for this to be recognised?
>> Is the type of media also another useful trait here?
>> (This was perhaps more relevant in the time of 10M,
>> when there was 10Base2, 10BaseT and 10Base5 connectors
>> all on the same NIC, but can still be relevant today
>> for identifying whether fibre or copper is in use.)
>>
>
> I think you are talking about a different type of property here, rather
> than something that dladm itself should have to deal with. Many ndd properties
> (see, for example bge_ndd.c in nevada) have different constraints based
> on the parameters you mention above. Essentially, the need for a replumb
> is directly related to how the driver itself can handle changes
> to the property.
>
Right. A lot of drivers will re-determine the MII phy address when the
link is down or has been down for a while, but some others may just
assume that the phy address is non-changeable.
Then you get into devices that don't even have an MII phy address...
they do something else. (E.g. early 10G nics lack any kind of MII
support at all, since there is no need to autonegotiate.)
>
>> I'd suggest having a command line option specific to
>> returning extended output, so you can have:
>> # dladm describe link_speed bge1
>> capabilities: 10M, 100M, 1G
>> possible: 10M, 100M
>> man page: bge(7)
>> blah blah blah blah...
>>
>>
>
> hm. So you are suggesting that we should have a new command line option.
> I have no preferences myself- I'd like to hear other thoughts..
>
It should probably dladm help.... to be consistent with other
utilities. See the "zoneadm help" command for more ideas.
-- Garrett
> --Sowmini
> _______________________________________________
> driver-discuss mailing list
> driver-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>
