Date: Tue, 25 Dec 2007 00:40:11 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Vlad GALU <dudu@dudu.ro> Cc: freebsd-net@freebsd.org, Peter Losher <Peter_Losher@isc.org> Subject: Re: Zero-copy BPF update (was: Re: Aggregating many ports into one for tcpdump server.) Message-ID: <20071225003638.N55818@fledge.watson.org> In-Reply-To: <20071224113901.M40176@fledge.watson.org> References: <4755EFDD.8070609@isc.org> <20071205021851.V87930@fledge.watson.org> <ad79ad6b0712050100p90a1917w5440e06a94f816e7@mail.gmail.com> <20071205093244.U87930@fledge.watson.org> <20071205094657.P87930@fledge.watson.org> <ad79ad6b0712050156m718c864fs23ccf43e126f8e83@mail.gmail.com> <20071224113901.M40176@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Dec 2007, Robert Watson wrote: > I've put up an updated tarball based on some recent changes here: > > http://www.watson.org/~robert/freebsd/20071226-zcopybpf.tgz Unfortunately, there was a problem with a change I made to the kernel check for a userspace notification that a buffer was available via shared memory, so I have updated the tarball. While there, I've made the following further changes: - bpf.4 has been updated to reflect the shared memory interface. - I've eliminated the BPF_ZEROCOPY environmental variable in libpcap; libpcap will try to use zero-copy BPF if it is compiled into the kernel and enabled. - The kernel now has a net.bpf.zerocopy_enable sysctl, set to 1 by default, which controls whether the kernel will allow new zero-copy BPF sessions to be created. - Memory barriers and atomic operations have been introduced on the shared memory interface to improve correctness on platforms with weaker memory consistency. Robert N M Watson Computer Laboratory University of Cambridge > > The main changes since this last drop are: > > - BPF_ZERO_COPY environmental variable renamed to BPF_ZEROCOPY to match > kernel > option name. > > - libpcap support for zero-copy BPF buffers reworked to avoid unconditional > call to select() for each buffer when there's already a pending buffer > available to use; in general, avoid system calls entirely when there's data > already waiting, only use system calls when there isn't a completed buffer > to work on next. > > - Comments cleanup and some code cleanup. > > - A README to provide a little more guidance on getting it working. :-) > > You will need to "make clean ; make ; make install" in the modified libpcap > against, as the size of pcap_t has changed. In principle "make ; make > install" should DTRT, but it appears not to for me. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071225003638.N55818>