2009/235 dladm Possible Values List

[James Carlson]

Mike Shapiro writes:
> > Telling administrators to suck out a number from the driver, and then
> > spit it back at the driver to "configure" the MTU means only that
> > users will blindly be baking in that one value for MTU on their
> > deployed systems -- and the value used will become just as stale over
> > time as the web sites, hack scripts, and sketchy documentation you're
> > lamenting.
> 
> I totally disagree: if the information is in the driver, then
> if for some reason it changes due to driver or hardware, then
> we've eliminated the problem of people having the wrong value.

No, we haven't.

The user will list out this "optimal jumbogram size" value exactly
once, when he's installing the system.  He'll use it to configure the
interface with this magical MTU value.

Days, weeks, or months later, he'll install a patch or update.  This
may change the optimal value.  But it will have zero effect on the
configured MTU: his value is now suboptimal, and we're back to the
world of web sites and documentation.

> > One possibly useful convention might help: the interface defined here
> > allows the driver to return a list of ranges for MTU.  If, by
> > convention, we tell driver writers to make sure that, where there are
> > non-trivial performance issues, the top number listed in any range is
> > the most efficient for that range, then you could (for instance)
> > display "1500-8150,8151-9000" for nxge.
> > 
> > Would that tweak allow this project to go forward without requiring
> > the design of a new network performance subsystem?
> 
> I don't understand how algorithmically that expresses, for example,
> which of 8150 or 8151 or 9000 is better to use, if one intends to
> deploy on a network with the max MTU set at 9000.

It expresses that the driver can go all the way up to 9000, and hints
that the sweet spots are the ends of the ranges -- 8150 and 9000.

If you _must_ have a value over 8150 in order to interoperate, then it
seems quite obvious to me that setting 8150 anyway won't help you.
You need the next larger value that the driver will handle reasonably
well.

If you don't specifically need a value over 8150 to do whatever it is
you're doing, then the appearance of that value at the end of a range
says "this is the largest value with consistent performance in this
range."

>  Why is having
> that value as a single separate attribute not simpler?

In part because I believe you're really talking about a different
project.  File an RFE.

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