>
> On Monday, July 16, 2001, at 12:57 PM, Bill Paul wrote:
> [...]
> > The chip has some nifty features though: hardware VLAN tag insertion
> > and removal, TCP/IP checksum offload on receive and transmit, 2048-bit
> > multicast hash filter, and 4 pattern match buffers for use with WOL.
>
> What is WOL?
Wake on LAN.
> > The transmit checksum offload has to be turned off if you use jumbo
> > frames larger than about 8K, because the chip only has an 8K transmit
> > FIFO. There is also support for interrupt moderation.
>
> Does it automatically not checksum packets >8K, or does A Bad Thing
> happen if you fail to turn it off first?
It does a Bad Thing (tm). In my testing, trying to send a frame larger
than 8170 bytes puts the transmitter to sleep. Normally, the chip
acknowledges transmit commands with three interrupt indications: TX DMA
done (packet was transfered to the chip), TX done (packet made it to the
wire), TX idle (TX queue empty, waiting for more packets). If you have
transmit checksums enabled and send a frame larger than 8170 bytes, you
get the TX DMA done interrupt, but nothing else. The transmitter stops
responding after that, and eventually a watchdog timeout is triggered
which resets the NIC.
The driver disables TX checksum offloading if you set the MTU above a
certain threshold. I think at that point, the performance gain from
using jumbo frames is greater than that of using TX checksum offload
anyway (for sustained transfers anyway).
For the record, the chip allows TX checksum offload on a global or
per-packet basis. I use the per-packet method, and simply don't set
the "I want TX checksums computed" bits in the TX DMA descriptors
once the MTU is set above the threshold (I also clear the if_hwassist
flags so the OS will go back to computing the checksums itself).
-Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
