Peter Memishian wrote: > > > Would the properties still end up in the show-linkprop output? If so, > > > even well-behaved admins are still subjected to a mountain of properties > > > that they shouldn't even be using, which seems bad. Or are you proposing > > > some way to hide these properties? (I'm nervous about that as well.) If > > > we're sure this stuff will be off the beaten path, maybe we could reduce > > > the number of properties to just `cap', `advcap', and `lpadvcap' (or > > > somesuch) with a commas-separated list of values? > > > > What we really need is a simple UI for managing the "common" tunables > > (and maybe exposing them as "properties" isn't the best way to handle > > this! see for example the way we handle WIFI "properties" for SSID... > > they have their own subcommands) > > Right, that was the thinking behind that breakdown. But I think most of > the tunables we've been discussing *aren't* that common -- at least, I was > kind of hoping most customers aren't mucking with fixed speed and duplex >
I think that hope is in vain. I still hear a lot of sites that have a stupid policy of forcing everything to some mode in their network (usually forcing everything to 100 full duplex.) We can debate the wisdom of this (or lack thereof, in which I suspect we are in agreement), but the reality is our customers are *still* demanding this support. > settings. Jumbograms are in a bit of gray area, but if we had a boolean > jumbograms property as you suggest, I think that'd be adminstratively > decent. One thing that we don't have is a nice way to separate out these "gray areas" (or areas where we expect customer tuning to be reasonable) from the areas where we expect tuning to be reasonable. I would prefer, all things being equal, if customers who didn't care about rx_bcopy_threshold settings were not exposed to them. (This tunable may need to be customer accessible, but it's reasonable that this adjustment require popping the hood of the automobile rather than being associated with a knob on the steering column.) The jumbo-frame, and also the link speed/duplex setting, by comparison, are the sort of thing that we need to be reasonably accessible to minimize service calls. I think of them as being like the traction control or over-drive adjustments in many late model cars... readily available for the folks who need them -- without checking the owner's manual or popping the hood, even though most people will probably never need to touch either one of them. I guess you could also liken them to the first or second gear selections on a vehicle with an automatic transmission as well. :-) > I'm curious why you think having three properties (ala cap, > advcap and lpadvcap) wouldn't be a reasonable tradeoff? > Because: a) that doesn't tell the whole story. (is autonegotiation enabled? that's another boolean! and having it disabled is a distinct case from having it enabled with only one mode advertised.) b) i guess having adv_cap be tunable via a comma delimited list would work, but it is likely to be more confusing than just "please force this mode" (which is what admins who diddle here really want) c) just setting a single forced mode is all (arbitrary unsubstantiated statistic alert!) 99% of the customers who do diddle here need... Given that this is the state of affairs, lets make case "C" above as easy as possible. > > Actually, the plethora of different jumbo frame sizes that various NICs > > support is *another* annoyance. I think we should just pick a standard > > Solaris value that is typical... say 9000 bytes or somesuch, and then > > abandon the attempts to support other less common "jumbo sizes". The > > infinite tunability here is more likely to cause problems for customers > > than to help them.) > > I'm inclined to agree, but I'm not familiar with what causes a customer to > choose a given value. > > I believe that most gigabit equipment supports 9000. Some equipment supports larger sizes, some (very uncommon) support some size > 1518 but less than 9000. I think its time someone here took a stand. 9000 bytes is a good size because it is nearly universal, and is sufficient to hold an 8K NFS block. A very few devices support 16K or even higher, but the utility of such large MTUs is probably somewhat limited... even at 10Gb. And the interoperability concerns with such large MTUs abound. Further, the ethernet CRC-32 breaks down somewhere around 12K, so larger frames than 12K are a bad idea with ethernet. A few references: http://sd.wareonearth.com/~phil/jumbo.html http://www.networkworld.com/forum/0223jumboyes.html http://en.wikipedia.org/wiki/Super_jumbo_frame http://www.sun.com/products/networking/ethernet/jumbo/index.html That last reference suggests that we (Sun) support 9K frames, which while not entirely uncommon, is nothing near as common as the normally accepted value of 9000 bytes. -- Garrett
