On Wed, 30 May 2001, Dave Siegel wrote:
There will obviously be different packet handling techniques for the larger packets,
Why will there "obviously" be different packet handling techniques? is there a special routine for packets over 1500 bytes? 4470 bytes? Or do you mean policy mapping jumbo packets into dedicated queues?
Generally, yes. There are often different memory pools for different sized packets.
and I'm not aware of any performance or stability testing that has been done for jumbo frames. I'm guessing the people who are actively using them havn't been putting it in line rate mixed small and large packets conditions.
Probably not, but if you take a person who is using them and let them use your backbone as a point to point network, you start to see that...not at line rate (preferably, anyway) but certainly large quantities of small packets mixed in with some really big ones.
My gut instinct is that there are very few people who have fully tested their products at close to line rate speeds with a full mix of small and jumbo frames, but I'd love for someone to prove me wrong.
Where your possible QoS impact comes in is where you have jumbo packets sitting in the best effort queue, and small frames sitting in your priority queue, you have some queue contention. This doesn't happen so much as a result of having the large packet there, but rather because your minimum queue size has to be of sufficient size to carry the packet. The linecard is going to spend more time draining the best effort queue while the priority queue gets stacked.
Even without QoS, what do jumbo frames do to overall buffer utilization? (I would imagine nothing, since I suspect this is a function of line speed, not packet size).
True, if you're running a very congested gige pipe with jumbo frames taking a large amount of the traffic the smaller frames may be delayed. Many jumbo frame implementations have seperate queues for regular vs jumbo frames, I know at least the Alteon products do. I'm not sure if anyone is intelligently using this to provide a WFQ-like service though. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)