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

[Pyun YongHyeon]

On Mon, Feb 06, 2006 at 03:24:50PM -0800, 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
 > >>>
 > >>>
 > >>>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 

AFAIK FreeBSD doesn't embed the length of the L3 header in csum_data.
If we do that it would help much for hardwares that lacks hardware
pseudo checksum capability.(e.g. hme(4), sk(4) etc) ATM these drivers
should find out L3 header length by traversing the mbuf chain.

 > 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

-- 
Regards,
Pyun YongHyeon