cvs commit: src/sys/dev/bge if_bge.c

Bruce Evans bde at zeta.org.au
Tue Feb 7 01:44:58 PST 2006


On Mon, 6 Feb 2006, Nate Lawson wrote:

> Nate Lawson wrote:
>> Oleg Bulyzhin wrote:
>> 
>>> On Mon, Feb 06, 2006 at 02:21:09PM -0800, Nate Lawson wrote:
>>> 
>>>> Oleg Bulyzhin wrote:
>>>> 
>>>>>         nq = q->m_nextpkt;
>>>>>         q->m_nextpkt = NULL;
>>>>>         m->m_pkthdr.csum_flags &= q->m_pkthdr.csum_flags;
>>>>> -        m->m_pkthdr.csum_data += q->m_pkthdr.csum_data;
>>>>> +        sum = m->m_pkthdr.csum_data + q->m_pkthdr.csum_data;
>>>>> +        m->m_pkthdr.csum_data = (sum & 0xffff) + (sum >> 16);
>>>>>         m_cat(m, q);
>>>>>     }
>>>>> #ifdef MAC
> ...
> Sam Leffler mentioned this comment from NetBSD would be helpful.  Might you 
> add it to clear up misunderstandings like I had?
>
> sys/mbuf.h has useful comments not found in the freebsd file:
> ...
> * Note for in-bound TCP/UDP checksums, we expect the csum_data to NOT
> * be bit-wise inverted (the final step in the calculation of an IP
> * checksum) -- this is so we can accumulate the checksum for fragmented
> * packets during reassembly.
> */

This almost makes the carry-folding (including the above change)
unnecessary too.  csum_data can accumulate at least 64K terms each
less than 0x10000 before it might have a carry out of its 32-bit int.
I think there can't be 64K fragments, so the unpatched version would
work if the final step did the carry-folding and no intermediate step
assumes that csum_data < 0x10000.  I couldn't find any final or
intermediate steps that would cause problems.

Bruce


More information about the cvs-src mailing list