2009/235 dladm Possible Values List

[Garrett D'Amore]

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.

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.

-- Garrett
> -Mike
>
>