Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Feb 2006 20:44:42 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Nate Lawson <nate@root.org>
Cc:        Alan Cox <alc@cs.rice.edu>, src-committers@freebsd.org, Oleg Bulyzhin <oleg@freebsd.org>, cvs-all@freebsd.org, cvs-src@freebsd.org
Subject:   Re: cvs commit: src/sys/dev/bge if_bge.c
Message-ID:  <20060207201220.W4040@epsplex.bde.org>
In-Reply-To: <43E7DAC2.8060101@root.org>
References:  <200602020958.k129wWtc066930@repoman.freebsd.org> <20060202100637.GB24350@lath.rinet.ru> <20060205235817.GQ5499@cs.rice.edu> <20060206221141.GA57775@lath.rinet.ru> <43E7CBD5.5090203@root.org> <20060206223436.GB57775@lath.rinet.ru> <43E7D662.6000608@root.org> <43E7DAC2.8060101@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060207201220.W4040>