2009/235 dladm Possible Values List

[Mike Shapiro]

On Tue, Apr 14, 2009 at 11:42:42AM -0700, Garrett D'Amore wrote:
> 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 still remain unconvinced here.
> 
> If the traffic pattern can push 9000 byte packets, then I think that is 
> what you should use for your MTU.
> 
> If your pattern (at your site) is 8K packets, and you *know* that (and 
> the pattern can't fill a 9K packets), then *perhaps* you should consider 
> using a smaller MTU. (Of course, there are a lot more decisions that 
> need to come into play. For example, what kinds of 802 bridges if any 
> are in play -- fragmenting packets is *expensive* -- and what are the 
> efficiencies of all the other hardware in your system?)
> 
> In the Jumbo Frame arena, the most commonly supported size is 9K. 
> Hardware and device drivers should, where possible, be designed to make 
> this as efficient as possible.
> 
> What I think you're asking for, "optimal_jumbo", is really 
> "minimum_dma_overhead", and is inherently very specific to the 
> implementation -- its just one aspect of choosing the "optimum" MTU. 
> Calling it "optimum" is a misnomer that I think will lead to great 
> confusion. And, furthermore, I expect that it will lead to a greatly 
> increased number of service calls.

Naming aside, if you set the network at 9000 and then the driver
at something smaller which is better, then you get the benefit.
 
> Overall, this feels really like a "benchmark special" to me. If your 
> driver has some particular behavior where 9K packets take a significant 
> penalty that 8K do not, then this rightly should be treated in two ways:
> 
> 1) as a bug -- the hardware/software should have been optimized to make 
> 9K efficient as it is the most commonly deployed frame size
> 2) in documentation as a note in the man page.
> 
> Both of these treatments are appropriate -- this isn't an either/or 
> situation, I think.

As a software guy I agree.  However, (1) you don't get to control:
that's under the control of hardware design people and subject to
other factors.  And (2), which is the entire point of why I brought
this up, is unlikely to be seen, and prone to error or staleness.

-Mike

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