[brussels-dev] Brussels- nddcompat code review

[Sebastien Roy]

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