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