Josh Graessley writes:
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.
Just did, thanks..
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.
Hehe.. Yes, but all the world's not a GMAC. It appears that the GMAC specific code has replaced the general code. Eg, if you set CSUM_DATA_VALID without setting CSUM_TCP_SUM16, you're ignored. The only to not be ignored is to set either CSUM_PSEUDO_HDR or CSUM_TCP_SUM16. Setting CSUM_PSEUDO_HDR gives me the same problem -- no frags can be dealt with unless I want to implement reassembly in my driver (I don't). So I'm screwed either way. There should be a 3rd case. Eg: --- tcp_input.c Sun Dec 16 10:59:16 2001 +++ tcp_input.c.new Tue Jan 29 11:06:45 2002 @@ -520,7 +520,10 @@ else { if (m->m_pkthdr.csum_flags & CSUM_PSEUDO_HDR) th->th_sum = m->m_pkthdr.csum_data; - else goto dotcpcksum; + else + th->th_sum = in_pseudo(ip->ip_src.s_addr, + ip->ip_dst.s_addr, htonl(m->m_pkthdr.csum_data + + ip->ip_len + IPPROTO_TCP)); } th->th_sum ^= 0xffff; (similar for udp_input()). Drew