cvs commit: src/sys/dev/bge if_bge.c
pyunyh at gmail.com
Mon Feb 6 16:36:10 PST 2006
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
> * 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.
More information about the cvs-src