2009/235 dladm Possible Values List

[Mike Shapiro]

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

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

I agree the end-to-end tuning this much more complicated, which
is why I'm attempting to identify a specific sub-problem that
can and should be solved that improves the situation.

> 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.  Why is having
that value as a single separate attribute not simpler?

-Mike

-- 
Mike Shapiro, Sun Microsystems Open Storage / Fishworks. blogs.sun.com/mws/