Yes, it's me. I'm still alive. And thanks to Wind River, I now know more about the Intel 8255x ethernet chipset than I ever really wanted to. Recently, I even learned how to enable checksum offload support for the 82550 and 82551 chips, and I decided it would be a good idea to add support for this to the if_fxp driver. There's a modified version of the code from 5.0-CURRENT sitting at:
http://www.freebsd.org/~wpaul/Intel The bulk of the changes are in if_fxp.c and if_fxpreg.h. I've been testing this on 5.0-RELEASE, using 82557, 82559 and 82550 cards, and so far it seems to behave as expected. I would like to commit this, but first I want to make sure I'm not stepping on anyone's toes by doing so. I don't know who (if anyone) is maintaining the fxp driver at this point. (I think jlemon was doing, but don't know if he still is.) Some background: The 82550 and 82551 chips are newer than the 82559, even though their part number is lower. The 82559 has limited RX-only checksum offload capabilities. The 82550 and 82551 have IP and TCP/UDP checksum support for both TX and RX, using extended RX and TX descriptor structures. (Computing checksums across fragmented packets is _not_ supported.) The programming info used to enable the checksum offload support comes from the manual and driver source at: http://www.sourceforge.net/projects/e1000 Now, you'd think that the manual alone would be enough, but it isn't. The documentation describes the operation of TX checksum offload, which is implemented using a special command block called an IPCB. This is essentially an extended TxCB, except that where a TxCB contains two fragment pointer/length pairs, an IPCB has just one, and the extra space is used to control the packet parsing and offload capabilities. The manual also mentions the existence of extended RFDs for receive checksum offload, but the stupid thing doesn't tell you what they look like or how to enable them. For that, you have to go through Intel's Linux driver. It turns out there are extra bits in the config block that need to be set to enable extended RX mode. Also, the config block for the 82550 and 82551 is 32 bytes in size rather than 22. (The config bit to enable "magic receive mode" is in byte 23.) Adding support for these features while maintaining support for older chips (without making massive code changes) was a bit tricky. I don't think I did all that great a job of it, but it works. Basically, I overlaid the new IPCB structure pieces over the existing TxCB using a union. This allows the existing structure layout to be preserved for the benefit of older chips. There seems to be one annoying bug in TX checksum offload: the chip appears to botch IP header checksums for IP fragments containing less than 4 bytes. One of the tests I ran was to send a UDP packet of 1473 bytes, which ends up being fragmented across two IP datagrams, the latter containing only 1 byte of actual data. For some reason, the chip doesn't compute a proper checksum for this fragment. Consequently, TX IP header checksumming is turned off by default. If you compile the driver with -DFXP_IP_CSUM_WAR, you'll get some workaround code that attempts to hand-patch the IP checksum for datagrams of 1 to 3 bytes in size. This is not used by default because I don't consider it to be reliable, nevermind pleasant to look at. I only have access to an 82550 card, so I don't know if this is fixed in the 82551 or not. Unless anybody complains loudly, I'd like to commit this soon. I'm fairly confident that (at the very least) it doesn't break any existing functionality. Unfortunately, I'm not in a position to do in-depth performance tests right now. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems ============================================================================= "If stupidity were a handicap, you'd have the best parking spot." ============================================================================= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
