This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB5276632F6BA99282EE800E1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

First, thanks for your reply.  More in-line.

Jonathan Stone wrote:

>In message <4387A5BC.3000403@tastylime.net>Jeff Rizzo writes,
>
>  
>
>>Before I beat my head against this too much more, I thought I should ask
>>here -
>>
>>what's the word on "jumbo frames" support in NetBSD?
>>    
>>
>
>Jumbo frames are a non-standard. Ergo, support for "jumbo frames"
>depends on the vagaries of individual hardware chips; sometimes even
>on variants within a family. Therefore it doesn' tmake sense to ask
>about "jumbo frame" support in NetBSD, other than on a
>device-by-device (or chip-variant by chip-variant) level.
>  
>

Well, it might make sense if there was some coordinated effort to tie
this together - that's why I asked.  (I didn't think there was, but
figured I should ask).


>>I was interested
>>in adding it to the sk(4) driver, but wanted to get a look at what
>>working support was like, first... i've been unsuccessful at getting it
>>to work with a couple of re(4) boards (the man page says the chips don't
>>seem to support past an MTU of 7500, but I wasn't able to get 4500 to
>>work), or a couple wm(4) boards  (ping -s 2002 works, ping -s 2003 does
>>not).
>>    
>>

wm(4) seems to have issues - I tried Dheeraj Reddy's port[1] of the
em(4) driver from Intel, and the same cards work great right up to (and
possibly past) 9000 bytes, although there's a note about known
performance issues with UDP+jumbos.

>
>I don't recall if I wrote that, or if Wiz added it, or if it predates
>the gigabit/cardbus chips; but (if memory serves) that's exaclty what
>the 8169/8110S datahseets say.  From memory, the 8169/8110S can
>receive up to 9000-odd bytes, but (due to a Tx FIFO limit) can
>transmit at most 7500 bytes. (Or maybe I'm mixing up re(4) with that
>absurd Netgear GA-620T...)
>
>  
>

I saw the note in the re(4) man page, but was unable to get things to
work with much smaller frames... 4500 bytes, iirc.  (Since realtek is
so, um, crappy in general, I've mostly not worried about them, but since
the man page was explicit about it, I thought I'd try)

>  
>
>>I _have_ been able to get jumbo frames working with a bge(4) board, and
>>with a pair of ti(4) boards I have.  (No great amount of testing, but
>>with an MTU of 9000, "ping -s 8972" fits everything into a single frame,
>>and gets a successful echo reply).
>>    
>>
>
>Hmm. Was it me who added jumbo support to our bge(4) driver? If it
>was, I don't recall if it was ever disabled it for the non-"server"
>PCI-e chips which don't support jumbo frames (or for the 5721, which
>according to marketing datasheets can do jumbo frames, but requires
>special massaging not, AFAIK, present in the Linux drivers or in any
>*BSD bge(4).
>  
>

This is a 5701, and seems to mostly work. I say mostly, because with a
little testing, I just discovered it seems to have problems past 8998
bytes, though it claims to support to 9000. 

>
>Also be aware that, since "jumbo" frames are a non-standard, there's
>no standard agreement on jumbo-frame length. the bge(4) devices
>support 9000 bytes. Other hardware aims 9128 bytes, presumably
>insipred by the ATM LAN-emulation (LANE) MTU.  And then there's the
>Intel cards, where some variatns supported jumbo frames up to 16k. 
>(Good luck finding a switch which can handle _those_.
>  
>
>Then again, if you've gotten as far as you say, quite possibly you
>know all of the above already.
>  
>

Yes, I knew most of it - at this point I'm still avoiding a switch (no
need for yet _another_ variable) and am doing primarily back-to-back
testing.  I just wanted to make certain the issues I was seeing were
driver-specific, and not systematic. With the added confirmation of
Intel's driver handling jumbos better, I have a much better sense that I
know the state of things, and can proceed with relative confidence that
I'm not missing something major.  Thanks much for your reply.


+j

[1] http://users.ece.gatech.edu/~dheeraj/NetBSD/sys_em.tar.gz

--------------enigB5276632F6BA99282EE800E1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQCVAwUBQ4ewnrOuUtxCgar5AQPk4AP/cDBGigaG/PauoDM6WVWdkVT4qdhZx1WZ
hT/iBUd6wCQ2GgT6tAF9E+Gox+CgGPdPF2va+Rz7bP276MtKaJ/oPrPMYAHFv10V
sV+LbCUxARxQQS1CrOGlCsKOXFqmM8/aglZiYCwxOESPe+bKsVL2cgsU0OSngNPb
I0Apfmc0+1M=
=zrTa
-----END PGP SIGNATURE-----

--------------enigB5276632F6BA99282EE800E1--