On 1/28/02 1:22 PM, "Andrew Gallatin" <gallatin@cs.duke.edu> wrote:

Hi,

I've got an "ethernet" device which can do TCP/UDP checksum offload on

receive, but not transmit.

In ip_input(), darwin discards checksums on packets from devices whose

if_hwassist is set to 0. However, in the original FreeBSD code,

if_hwassist is meant only to tell what sort of transmit offloading a

device will do.

To make recv. checksum offloading work with my device, I needed to set

if_hwassist to a non-zero value which is nonsense wrt to xmit offload

capabilities. This seems broken to me.

I believe the check for if_hwassist was done to try and cover up any bugs. I think it was thought that if the interface that packet was received on did not support hardware checksums then it must have set those bits by accident. Not very helpful. You might want to file a bug against this.

Also, why does darwin not allow csum offloading for received ip

fragments using the CSUM_TCP_SUM16 method?

The CSUM_TCP_SUM16 flag is used to indicate that the GMAC's checksum is being used. The GMAC hardware checksum has some limitations. There are a lot of checks for the various limitations to avoid cases where the hardware does the wrong thing. I believe IP fragments may be one of the cases where the chipset does the wrong thing.

BTW, its rather amusing. I loose roughly 100Mb/sec when I turn on

receiver offloading (800Mb/sec -> 700Mb/sec). I know the settings are

correct, because UDP tests show a reduction in drops due to full

socket buffers when csum offloading is on. This is a dual g4-800.

I've seen platforms where csum offload doesn't make much difference,

but this is the first platform I've seen where it actually hurts!

Weird. -josh