On Tue, 2009-05-12 at 14:37 -0400, Dale Ghent wrote: > On May 12, 2009, at 11:09 AM, Sebastien Roy 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. > > 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.
That is not the case. E.g.: bash-3.2# dladm show-linkprop -p mtu bge0 LINK PROPERTY PERM VALUE DEFAULT POSSIBLE bge0 mtu rw 1500 1500 1500-9000 bash-3.2# dladm set-linkprop -p mtu=9000 bge0 bash-3.2# dladm show-linkprop -p mtu bge0 LINK PROPERTY PERM VALUE DEFAULT POSSIBLE bge0 mtu rw 9000 1500 1500-9000 > 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. What you're advocating for is exactly what the implementation does. Convenient, isn't it? ;-) > 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? I believe that the deployment that sparked the discussion is specific to a single NIC that has hardware properties that result in a single optimal value that is different than the maximum value. > 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. I believe the idea is that jumbo frames enabled at an MTU slightly less than the maximum would provide better performance than the maximum MTU. Obviously, all of the devices on the affected link would need to tweak their MTUs to the exact same value, and that part would be the responsibility of the network administrator. -Seb _______________________________________________ networking-discuss mailing list [email protected]
