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. >From a programmatic perspective, the point is simple: the optimal MTU is a function of the driver and the hardware. 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. -Mike -- Mike Shapiro, Sun Microsystems Open Storage / Fishworks. blogs.sun.com/mws/ _______________________________________________ networking-discuss mailing list [email protected]
