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>