Sowmini.Varadhan at Sun.COM wrote: > On (03/27/08 09:05), Sebastien Roy wrote: >> Right, so given that the clamping to a minimum of 1500 by bge is a bug, >> why would libdladm legitimize that be stating that the minimum for all >> Ethernet links is 1500? If there are different possible values per >> driver, then perhaps something is missing to obtain those possible >> values per-link? >> >> Right, I know that it's the convention from jumbo frame. What I worry >> about is 3rd party driver developers working on something outside of the >> ON consolidation (so they don't have the option of recompiling >> libdladm), perhaps "super jumbo frame". They can't do that, since >> libdladm artificially limits the MTU to 9000. This doesn't seem like a >> good thing to me. > > Actually, the "Possible" part is just Advisory. In the example that you > cite (3rd party working on sjf) nothing would prohibit them from using > dladm- the output would just be out of sync with the behavior.
Ah, I see. So this isn't as bad as I thought, but still not good. > As for obtaining possible values for the link, I am starting to think > that this should be done with a separate property, similar to > the WL_DESIRED_RATES prop for wifi. However such a property would have > to be able to print ranges (e.g., "1500-9000" for bge) or discrete values > (as is done with WL_DESIRED_RATES), so the data passed in/out of the > property would need to be designed after some consideration. so I'm going > to defer this for later, and leave the current behavior for this unchanged. Sure, that's fine with me. Can a CR be filed to track this? -Seb
