On May 12, 2009, at 2:30 AM, 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.
Finding/divining the proper jumbo MTU for a particular interface,
whatever the value of jumbo may be, has always been an area of Solaris
(well, almost any OS) that I've pined for improvement. Not only can
the max usable MTU (switch hardware permitting) be hard to find,
usually by digging through the driver's .conf file, but setting it as
well without having to reboot, or if you're lucky and sly, doing a
modunload/modload of the driver after changing the right (and
inconsistent across drivers) field in the .conf file.
Some drivers, such as e1000g, hint at being able to set super jumbo
frames of 16k in size. Others top out at the universally-recognized
jumbo mtu of 9000. Yet one driver (the name of which escapes me)
allows a 9120 byte mtu.
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.
I just hate having to go on safari through kstats, driver conf files,
or driver source to see what a particular interface is capable of.
Listing interface capability in dladm and being able to tweak the MTU
freely via the normal route of 'ifconfig <interface> mtu X' would be
just awesome.
Here's an exercise: You have a machine with both e1000g and nxge
interfaces, such as a T5220 for example. Go forth and turn on jumbo
frames for both interface types and only for instance 0 of either
interface type. Note the vastly different ways of doing it.
/dale
_______________________________________________
networking-discuss mailing list
[email protected]
