Re: tcp/udp hardware checksum offload support..
Re: tcp/udp hardware checksum offload support..
- Subject: Re: tcp/udp hardware checksum offload support..
- From: Andrew Gallatin <email@hidden>
- Date: Tue, 29 Jan 2002 16:34:19 -0500 (EST)
Josh Graessley writes:
>
CSUM_TCP_SUM16 is only for the GMAC hardware, you shouldn't need to set it
>
for your hardware. It only causes some weird special case code to be
>
executed. Ideally, you should be able to get things working with the other
>
flags. The hardware checksum support in the kernel is still new, so it may
>
contain some rough edges you'll get snagged on, as you're noticing. Some of
>
this is addressed on a branch we're working on.
>
I don't recall what the psuedo header does. Perhaps someone else can help
Do you mean the CSUM_PSEUDO_HDR flag? It means the device has
checksummed the entire packet (including the psuedo header) and has
left the csum in csum_data.
>
out there. I do know that you can't perform hardware udp/tcp checksums on
>
fragmented packets unless you're going to handle reassembly in your
>
hardware. The UDP or TCP checksum is in the first fragment that contains the
>
UDP or TCP header. All other fragments of the packet contain the IP header
>
followed by UDP or TCP data. You can't calculate the UDP/TCP checksum until
>
you've collected all fragments. I believe most stacks avoid TCP
>
fragmentation, so I doubt you'll see much if any of that. This will still be
>
a problem from UDP though.
Yeah.. I don't want to collect all the fragments -- I want ip_reass()
to collect them because that's its job. Eg, I want to pass the
payload checksums up the stack and have ip_reass() add things up.
In fact, if you look at the code, its already adding the csum's up in
the "Concatenate fragments." section of ip_reass. All that needs to
be done is to fix the proto layers to call in_pseudo() to adding the
psuedo header sum on packets without CSUM_TCP_SUM16 or CSUM_PSEUDO_HDR
set & I'll be a happy camper.
FWIW, this is how it works in FreeBSD.
Cheers,
Drew