Date: Tue, 26 Aug 2008 10:47:54 +0300 From: Stefan Lambrev <stefan.lambrev@moneybookers.com> To: gnn@freebsd.org Cc: "Bruce M. Simpson" <bms@freebsd.org>, Luigi Rizzo <rizzo@iet.unipi.it>, net@freebsd.org Subject: Re: Small patch to multicast code... Message-ID: <48B3B52A.9080400@moneybookers.com> In-Reply-To: <m2hc9chh0c.wl%gnn@neville-neil.com> References: <m27iaa6v43.wl%gnn@neville-neil.com> <20080821203519.GA51534@onelab2.iet.unipi.it> <m23aky6ncl.wl%gnn@neville-neil.com> <48AE23FF.9070009@FreeBSD.org> <m2tzdd6j36.wl%gnn@neville-neil.com> <48AF08B7.4090804@FreeBSD.org> <20080822194200.GC63527@onelab2.iet.unipi.it> <m2hc9chh0c.wl%gnn@neville-neil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Greetings, gnn@freebsd.org wrote: > At Fri, 22 Aug 2008 21:42:00 +0200, > Luigi Rizzo wrote: > >> On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote: >> >>> gnn@FreeBSD.org wrote: >>> >>>> I gather you mean that a fast link on which also we're looping back >>>> the packet will be an issue? Since this packet is only going into the >>>> simloop() routine. >>>> >>>> >>> We end up calling if_simloop() from a few "interesting" places, in >>> particular the kernel PIM packet handler. >>> >>> In this particular case we're going to take a full mbuf chain copy every >>> time we send a packet which needs to be looped back to userland. >>> >> ... >> >>> In the case of ip_mloopback(), somehow we are stomping on a read-only >>> copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine >>> according to the documented uses of mbuf(9), although as Luigi pointed >>> out, most likely we need to look at the upper-layer protocol too, e.g. >>> where UDP checksums are also being offloaded. >>> >> in fact, george, if you have an easy way to reproduce the error, >> could you see if reverting your change and instead adding >> sizeof(struct udphdr) to the length argument in the call to m_pullup() >> fixes the problem ? >> > > I don't have sample code I can give but it's simple to set up and > test. > > On machine A set up a sender and a listener for the same multicast > group/port. > > On machine B set up a listener. > > Send from A with the listener on. B should see nothing and its "bad > checksums" counter should increase. > > Turn off listener on A. > > Send again, B should get the packet. > Hm this looks very much like the showstopper when trying to use jboss in cluster environment. The nodes are replicating their data using multicast udp. I'll try this patch to see will the cluster work now under FreeBSD. > If you listen to the traffic with tcpdump on a 3rd machine you'll see > that the checksum is constant, even if the data in the packet, like > the ports, is not. > > Your ethernet cards have to have hardware checksum offloading. I'm > using em/igb in 7-STABLE. > em cards and here. Jboss in cluster creates lot of traffic when under pressure, so I wander how this patch will affect performance. > Best, > George > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Best Wishes, Stefan Lambrev ICQ# 24134177
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48B3B52A.9080400>