Re: Jumbo Frames in 10GbE?

[ted@xxxxxxxxxx (Ted Schroeder)]

Needless to say I've been reading the commentary on Jumbo Frames
with extreme interest since my company ships switches and
NICs that use jumbo frames.  One of the easy things to forget when
you're doing the analysis of jumbo frames versus small frames is
that you have to worry about frame size and packet count on both
transmit AND receive.  Many of the objections I've heard as things
go on is "just put hardware on the NIC to chop up the frames on 
the way out" (as is suggested below).  This works great for transmit,
but it doesn't do a darn thing on receive.  And receive is already
the place that hardest to get good performance on end systems.  With
jumbo frames many things, such as zero copy receive, can be done.
Without jumbo frames you have to do some sort of collection and
reassembly on the receiving side to allow zero copy receives to operate.
This is one of the big reasons why people are starting to look at
System Area Network solutions such as VIA and ST in conjunction with
Ethernet.

I don't want to trivialize the difficulties in solving the many valid
points brought up about difficulties in the switching/routing apparatus,
but let's not trivialize the issues in end station action either.

Ted Schroeder
Alteon WebSystems, Inc.

>I have also been listening to this and have succumbed to the urge to
>reply.  As a DESIGNER of the equipment (switches now, NICs in the past)
>I also think that increasing the maximum frame size is not the thing to
>do.  It doesn't help the load on intermediate switches, and can
>complicate their design.  It would be easy (and natural, given the
>latest initiatives in distributed I/O) to have the NIC perform flow
>segmentation and reassembly.  You don't even need larger hardware
>buffers, just some more gates, since the NICs pull data out of the
>system memory already.  This would provide a larger performance increase
>than Jumbo, and it will add differentiation in the NICs, which means it
>will arguably happen anyway (much like a desire for differentiation is
>prompting *this* discussion).  A smarter NIC would be completely
>transparent to the network administrator, it would exist completely
>within current standards, and it would work regardless of the media and
>speed.  Do we soon want to be left with the cost of supporting large
>frames when the reason for having them is obsolete? 
>
>The IEEE shouldn't waste time working with larger frames until it can
>answer all the relevant questions (such as how to encapsulate large
>frames, how bridges should handle these packets, what new stats will be
>required, market desire versus complexity, etc.)  These are not issues
>for the HSSG.  If we find that we *could* support larger frames for
>little or no extra cost with option A versus option B, fine, we'll
>select option A in case Jumbo gains more support.  This reflector should
>limit discussions to something closer to: is there a way to cost
>effectively ensure that a future Jumbo standard would run over this
>media? 
>
>Ethernet has become the success that it has by delivering 1000%
>performance steps with practically no added complexity, certainly
>nothing like *not enabling transmission* of certain packets on certain
>links.  I certainly wouldn't enjoy explaining to a network administrator
>why he can't mirror packets from a server to a protocol analyzer. 
>
>I would've asked for an informal show of hands to see the actual
>interest level on both sides but I think that we already did it
>officially in Idaho. 
>
>-Simon L. Sabato
>-Level One Communications
>