On Tue, May 12, 2009 at 01:25:11PM -0400, James Carlson wrote: > > dladm already does both of these things (via the mtu link property). > > The discussion is about going beyond that and providing some sort of > > optimum values for this existing property. > > To be more specific -- it's a performance thing. There are apparently > a few drivers for which the largest allowable configured MTU is _not_ > also the MTU that will result in the best application performance > ... for some given definition of what "application" we're talking > about and specifically what "performance" means in that context. (I > suspect "application" means either NFS or iSCSI and "performance" > means only "throughput," but that's just a guess.)
That transports and applications could dynamically detect optimal message sizes in similar ways, provided that the protocols have something like do-not-fragment. I.e., do PMTUD but also have an iSER/SRP/RDDP/whatever extension by which you can ask the peer to tell the sender what is an optimal size -- the combination of PMTU and peer's local optimal MTU will tell you what is the optimal PMTU. (There's a variant of TCP PMTUD that does not depend on ICMP replies to do-not-fragment -- it probes the path MTU and responds to timeouts if the ICMP does not arrive. Solaris does not implement it.) > Opinions on this are all over the map. Some think that not having > best MTU == largest MTU is just plain a bug that should be fixed. > Some think that it's an important inherent characteristic, but too > fiddly to deal with from the CLI. Some think that it's absolutely > crucial to system deployment and thus must be automated and cannot be > dealt with by mere documentation. And there are probably valid > opinions between those as well. IMO the protocols in question need to dynamically adjust to local link and path characteristics. Nico -- _______________________________________________ networking-discuss mailing list [email protected]
