Nicolas Williams wrote:
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.
That would be a nice feature. If the "tuning" were automatic, and took
into account all the various implementations on the network, I'd be much
happier about this.
I'm very dissatisfied with the idea that we are going to provide some
kind of programmatic interface to some pseudo-precise value of "optimum
MTU".
I think I'd be happier with a proposal that for a kstat that offered up
a value for "optimum_dma_transfer" or somesuch.
And for the record, I do believe the situation where there is a
significant perf. difference between 8150 and 9000 bytes (where 9000
performs noticeably worse than 8150) is indeed a bug (most likely in the
hardware).
-- Garrett
Nico
_______________________________________________
networking-discuss mailing list
[email protected]
