Mike Shapiro writes: > On Mon, May 11, 2009 at 11:30:58PM -0700, Garrett D'Amore wrote: > > 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.
That's true, except that this isn't so simple. The "optimal" MTU to use also has to take into account the attached hardware and the peers. At least for Ethernet, the MTU must be set the same on all systems on a given subnetwork. That's inescapable. If the work in choosing the MTU to use is done only on the local hardware, then it may (like the "one port initiative") be optimal in some situations -- perhaps even financially important ones -- but is very likely to be highly suboptimal (and perhaps even non-functional) in others. And more importantly, cannot be made the default without violating both standards compliance and interoperability. There are protocols (such as LLDP) that might help a bit here in avoiding the serious blunders, but we unfortunately don't support them yet. In any event, I think Nico is onto a _much_ better answer that would automate the entire mechanism and avoid the need for any unusual administrative tweaking. -- James Carlson, Solaris Networking <[email protected]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
