Date: Tue, 7 Feb 2006 13:37:25 +0300 From: Oleg Bulyzhin <oleg@freebsd.org> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Alan Cox <alc@cs.rice.edu>, cvs-all@freebsd.org, Nate Lawson <nate@root.org> Subject: Re: cvs commit: src/sys/dev/bge if_bge.c Message-ID: <20060207103725.GA64400@lath.rinet.ru> In-Reply-To: <20060207201220.W4040@epsplex.bde.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> <20060207201220.W4040@epsplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 07, 2006 at 08:44:42PM +1100, Bruce Evans wrote:
> 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
You are right. If we are not going to reassemble more than 64k fragments we
can just add (into original ip_reass()):
m->m_pkthdr.csum_data =
(m->m_pkthdr.csum_data & 0xffff) + (m->m_pkthdr.csum_data >> 16);
right after for {} loop.
--
Oleg.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060207103725.GA64400>