Mike Shapiro wrote:
On Mon, May 11, 2009 at 11:30:58PM -0700, Garrett D'Amore wrote:
Peter Memishian wrote:
I still maintain that for arbitrary traffic, you cannot know the
"optimal" MTU, because you don't know what the overheads are. For
protocols with a very high per-packet cost, the DMA overhead of larger
packet might be in the noise, to the point that 9K is even better on
the > nxge configuration you've proposed.
I think the right answer is to document this information in the man
page > somewhere like this:
Documentation is useless as a programming interface, which is what e.g.,
Fishworks needs this for. The application can account for its own
overheads and provide whatever clues are necessary to help the driver work
together to find the right value, but leaving it to the documentation just
doesn't cut it.
--
meem
How do you programmatically handle this? 8150 is almost always
*wrong*. The only thing its good for is a benchmark special, or an
isolated network with just these kinds of devices on it. Everyone
everywhere else will use 9000 as that is the de-facto standard.
- Garrett
It's not a benchmark special, it's what is being shipped on
an entire storage product line right now because it has significantly
higher performance for nxge. As I said before.
If you're shipping this configuration enabled by default, then you're
asking for trouble. Big trouble. Because unless all the other peers on
the network are configured the same way (and this configuration would be
a major surprise to anyone else familiar with jumbo datagrams) Bad
Things Will Happen.
From a programmatic perspective, the point is simple: the optimal MTU
is a function of the driver and the hardware.
Disagree here. In this case, what you're talking about is the *optimal
MTU for DMA transfer performance*, which may or may not be the dominant
factor in performance. It depends on a number of other factors (such
as what type of traffic is in use, and ultimately what the per-packet
processing overhead for such traffic is -- and what is optimum for the
network peers. 8150 may be optimal for nxge on certain neptune
hardware, but setting it that way may incur a significant penalty to
network peers, which can also have a detrimental impact on perf.
Therefore if one wants
to write software to understand how to set the MTU or query the
optimal size, that should be a query to the driver, which returns
that as (for example) a new property.
IMO, you're micro-tuning, without looking at the "big picture issues".
The 8150 configuration is *not* going to be useful except in *very*
controlled environments. In a true heterogeneous environment, such a
configuration is probably going to be quite toxic.
-- Garrett
-Mike
_______________________________________________
networking-discuss mailing list
[email protected]
