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

[Nate Lawson]

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
>>>
>>>
>>> I'm not familiar with this code.  So m->m_pkthdr.csum_data is 32 
>>> bits? Couldn't the same thing be achieved with making it 16 bits 
>>> since the add will wrap normally?
>>
>>
>> It will not work cause it's not just a trivial sum it's so called
>> "1's complement sum" (refer rfc1071 for details).
> 
> 
> You're right, but aren't you missing the NOT step?
> 1. 2's complement sum
> 2. Add in carry
> 3. 1's complement of result (not)

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:

/*
  * record/packet header in first mbuf of chain; valid if M_PKTHDR set
  *
  * A note about csum_data: For the out-bound direction, the low 16 bits
  * indicates the offset after the L4 header where the final L4 checksum 
value
  * is to be stored and the high 16 bits is the length of the L3 header (the
  * start of the data to be checksumed).  For the in-bound direction, it 
is only
  * valid if the M_CSUM_DATA flag is set.  In this case, an L4 checksum 
has been
  * calculated by hardware, but it is up to software to perform final
  * verification.
  *
  * 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.
  */

Thanks,
-- 
Nate