2009/235 dladm Possible Values List

[Mike Shapiro]

On Tue, Apr 14, 2009 at 03:01:00PM -0400, Sebastien Roy wrote:
> 
> On Tue, 2009-04-14 at 11:33 -0700, Mike Shapiro wrote:
> > On Tue, Apr 14, 2009 at 02:00:16PM -0400, sowmini.varadhan at sun.com wrote:
> > > On (04/14/09 10:30), Mike Shapiro wrote:
> > > > 
> > > > (b) What is the jumbo size I ought to use with this card
> > > >     for optimal large MTU performance on the card?
> > > > 
> > > 
> > > Having a read-only property for optimal value per property per driver
> > > would not scale well as we add properties.
> > 
> > I'm not asking for an optimal value for every property: I'm asking
> > for a single property that indicates "optimal_jumbo" or whatever.
> 
> I'd like to make a suggestion unrelated to the technical merits of this
> idea.  There is value in this fast-track as-is, on its own.  If there is
> value in the "optimal MTU" idea, then it can also stand on its own (as
> Mike said, it could potentially be a separate read-only property).
> Therefore, the least contentious way forward would be to approve this
> case as-is while discussing the optimal MTU idea outside the context of
> this case (on networking-discuss at opensolaris.org for example).  If
> people can agree on a proposal for this, then it would be simple enough
> to file a small fast-track for it separately.
> 
> -Seb

Given the back-and-forth today, I think that is best.  The fundamental
point I would make is that the configuration of jumbos is (a) extremely
common for customers, (b) not easy to achieve optimal results, and (c)
has impact on the design of the property interface.  In my opinion
this issue is barely addressed in Solaris today, this case as it was
originally proposed solves one of the sub-problems nicely, but doesn't
solve some of the other problems, including the one I mentioned.

And the one I mentioned has direct impact on the interface being modified in
this case, which is why it ought to be considered now.  Also because we ought
to be actually solving the entire problem as best it can be (given the
protocol-level limitations), and not pretending that this is purely a doc
issue (with no action plan), or is simply not a problem (which it is, given
the many customers who ask about it).  As an example, the single biggest
call generator we've had around missing networking features for the
7000 series was the absence of jumbo support for LACP (now fixed) -- which
indicates how frequently this is used.

-Mike

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