On May 12, 2009, at 11:09 AM, Sebastien Roy wrote:
Dale,
On Tue, 2009-05-12 at 10:24 -0400, Dale Ghent wrote:
It would be great if one could:
1) set the max allowed MTU through dladm, or better yet, stop
pretending that 1500 is the universal max and just let it be set with
ifconfig, with 1500 being the default absent the mtu argument being
specified.
2) A dladm linkprop (read only) that shows the max MTU that is
supported by the driver. The drivers will have to advertise this,
which is a good thing - drivers should be advertising their
capabilities in a consistent and standard way. MTU, speeds supported,
any hardware checksum or offload capabilities, maybe even rings
active
and configurable.
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.
My experience is largely based on s10 right now, as I don't have a
machine handy which is running snv and has jumbo-capable interfaces,
so feel free to stop me cold in my tracks if I'm out of date on my
impressions here :)
My impression is currently under snv with brussels et al integrated,
dladm linkprop for a jumbo-capable interface will still only show a
max MTU of 1500 unless one has explicitly enabled jumbo frames via
whatever method that the driver in question demands, eg; a /etc/system
or driver.conf setting. Once jumbo frames are enabled, the jumbo-sized
MTU is then the default when plumbing a interface and visible in dladm
linkprops.
If this is indeed the case, the thing I'm advocating is to stop
treating jumbo frames as a special case and bring some consistency in
the individual drivers regarding turning it on (or making it
available), or dispensing with having to explicitly turn it on in each
driver and making its availability transparent - always there, but
with a default MTU of 1500.
As far how apropos jumbo frames are regarding application situations,
I think this is really a choice left up to the administrator, not all
too different from a admin deciding whether a 1Gb or 10Gb interface is
required for a certain app. Obviously jumbo frames are more nuanced
since it often requires jumbo frame capabilities being activated on
the remote end of the ethernet link.
Mr. Carlson talks of performance issues - do these concerns refer to
performance issues regarding the application and use of jumbo frames,
issues within a driver, or in the silicon? If the concerns lay in the
use of jumbo frames, that's a call for an administrator to make. If
it's a problem in a driver, shouldn't that be a bug? If the problem
with jumbo frame performance is in the silicon, well, if it can't be
worked around, then maybe we don't enable high MTUs or do so with a
well-documented caveat stating the implications.
/dale
_______________________________________________
networking-discuss mailing list
[email protected]
