2009/235 dladm Possible Values List

[James Carlson]

Mike Shapiro writes:
> I agree with the above, but you're describing the rest of the jumbo issue
> beyond what I'm getting at.  There are two completely different questions:
> 
> (a) What is the jumbo size I ought to set on this L2 network
>     given what is configured elsewhere on the network?
> 
> (b) What is the jumbo size I ought to use with this card
>     for optimal large MTU performance on the card?

They're distinct questions, but they're linked together in that you
can't really consider (b) without taking (a) into account as well.

At best, if we do what you're proposing, we could possibly do (b), but
we can't currently do the required component (a) -- at all.

> This is a significant issue for server and storage administrators,
> as is generally all issues of making Solaris networking perform better,
> and it's not effective to continue solving every problem with documentation.

This problem is much more complex than I think you're making it out to
be.

For instance, drivers change over time.  Code maintainers sometimes
discover that poor performance in a commonly-used configuration is a
bad thing (even if it was documented that way), and they then try to
find ways to fix the driver so that it does better.

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.

Figuring out how to get all of that sort of tuning right, and do so
over time, still sounds to me like something separate from this
project.

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?

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