Re: tcp/udp hardware checksum offload support..
Re: tcp/udp hardware checksum offload support..
- Subject: Re: tcp/udp hardware checksum offload support..
- From: Josh Graessley <email@hidden>
- Date: Mon, 28 Jan 2002 16:04:55 -0800
On 1/28/02 1:22 PM, "Andrew Gallatin" <email@hidden> 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