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

[James Carlson]

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.

The last survey of this I remember seeing was:

  http://darkwing.uoregon.edu/~joe/jumbo-clean-gear.html

> >> 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.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677