[networking-discuss] Re: [driver-discuss] Re: [brussels-dev] dladm show-linkprop enhancements

[Garrett D'Amore]

James Carlson wrote:
> Garrett D'Amore writes:
>   
>> James Carlson wrote:
>>     
>>> Garrett D'Amore writes:
>>>   
>>>       
>>>> 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.
>>>>     
>>>>         
>>> "Taking a stand" here means being deliberately incompatible with some
>>> other vendors.
>>>   
>>>       
>> Only a tiny, tiny minority of vendors who for some reason think it is ok 
>> to support a jumbo frame that is *less* than 9000 bytes.  I"ve only seen 
>> one case of that, from a very low end gigabit NIC.  (Which uses around a 
>> 7K jumbo frame, I think.)  I think those devices could just be 
>> considered "incompatible" with *everyone* else. :-)
>>     
>
> No.  It's also toxic with those vendors who choose to use something
> more than 9000 as well (such as, I think, 9180 on Cisco boxes).
>
> Your MTU is my MRU, at least when a shared medium is involved.
>   

True.  But I was assuming that all of the Jumbo Frame capable equipment 
could be configured not to send a frame larger than 9000 bytes.  Maybe 
this was a false assumption.  In the case of switches, any value greater 
than 9000 is sufficient, since they don't generally generate traffic of 
their own.  In the case of *routers*, I would _hope_ that the value 
would be tunable.

> The last survey of this I remember seeing was:
>
>   http://darkwing.uoregon.edu/~joe/jumbo-clean-gear.html
>   

Note that even he marks a boundary at 9000 bytes. :-)  If it can't 
support 9000 bytes, then it really isn't suitable for use with jumbo frames.

>   
>>>> 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 
>>>>     
>>>>         
>>> What if one of these other vendors "takes a stand" on 12K just to
>>> spite us?  Or if the IEEE itself finally decides to set a standard in
>>> this area and doesn't pick the same value?
>>>   
>>>       
>> The former would be hard, because it would be incompatible with a *lot* 
>> of devices that simply cannot do 12K.  They'd be cutting off their nose 
>> to spite their face.  The latter seems incredibly unlikely for the same 
>> reason.
>>     
>
> I agree that 9000 is "likely."  I'm not so sure I trust the other
> vendors involved here enough to say that it's certain.
>
>   
>>> I think we're on really shaky ground here.  I completely agree with
>>> having a default jumbogram size, I agree with making it 9000, and I
>>> agree with making it "hard" to change.  I don't agree that we ought to
>>> make it completely unchangeable just to force the issue.
>>>   
>>>       
>> Okay, I didn't necessarily mean to say there would *no* way to change 
>> it, only that changing it should be something almost never done, and 
>> only then by opening up the hood, so to speak.  A choice of some value 
>> other than 9000 is akin to choosing a different inter-packet gap 
>> timing... there may be some unusual application for it, but I'm not sure 
>> it deserves "first class" support (including the same level of QA 
>> coverage!) that the reasonable default gets.
>>     
>
> Fair enough; it shouldn't be the common path.
>
>   

Okay, I think this sounds like consensus. :-)

    -- Garrett