Small patch to multicast code...

[gnn at freebsd.org]

At Tue, 26 Aug 2008 17:56:13 -0700,
Sam Leffler wrote:
> 
> gnn at freebsd.org wrote:
> > At Tue, 26 Aug 2008 14:50:33 +0000 (UTC),
> > Bjoern A. Zeeb wrote:
> >   
> >> On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
> >>
> >> Hi,
> >>
> >>     
> >>> At Mon, 25 Aug 2008 21:40:38 +0200,
> >>> John Hay wrote:
> >>>       
> >>>> I have tried it and it does fix my problem. RIP2 over multicast works
> >>>> again. :-)
> >>>>         
> >>> Good to hear.  I'm waiting on a bit more feedback but I think I'll be
> >>> checking this in soon, with a big comment talking about the
> >>> performance implications etc.
> >>>       
> >> So wait a second; what was the m_pullup vs. m_dup thing? Has anyone
> >> actually tried that? I mean using a sledgehammer if a mitten would be
> >> enough is kind of .. uhm. You get it.
> >>     
> >
> > Perhaps I'm confused, I've been off dealing with other issues for a
> > few days, but m_pullup doesn't make a copy of the packet or its
> > fields, only makes sure that it's contiguous in memory.  Am I wrong in that?
> >
> > Since the bug is that two pieces of code modify the same data, in ways
> > that interfere, I'm not sure how we can avoid making a copy.  It might
> > be nice to limit the copy, but we'd still need two copies, one for the
> > loopback device and one for the real device.
> >
> >   
> pull the headers up.  copy just the headers.  no deep copy.
> 

I'm confused, if it's these lines that are screwed up:

		/* If needed, compute the checksum and mark it as valid. */
		if (copym->m_pkthdr.csum_flags & CSUM_DELAY_DATA) {
			in_delayed_cksum(copym);
			copym->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA;
			copym->m_pkthdr.csum_flags |=
			    CSUM_DATA_VALID | CSUM_PSEUDO_HDR;
			copym->m_pkthdr.csum_data = 0xffff;

in particular that last line, then how does pulling up the header
help?  That's not part of the packet, that's the checksum data in the
pkthdr itself.

Best,
George