From owner-freebsd-current@FreeBSD.ORG Mon Mar 24 14:15:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4E881065670; Mon, 24 Mar 2008 14:15:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7753A8FC13; Mon, 24 Mar 2008 14:15:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4E55746C0D; Mon, 24 Mar 2008 10:15:51 -0400 (EDT) Date: Mon, 24 Mar 2008 14:15:51 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Christian S.J. Peron" In-Reply-To: <20080324140623.GA14941@sub.vaned.net> Message-ID: <20080324141334.T7797@fledge.watson.org> References: <20080317133029.GA19369@sub.vaned.net> <20080317134335.A3253@fledge.watson.org> <20080324140623.GA14941@sub.vaned.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, freebsd-current@freebsd.org, net@freebsd.org Subject: Re: HEADS UP: zerocopy bpf commits impending X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 14:15:53 -0000 On Mon, 24 Mar 2008, Christian S.J. Peron wrote: > I just want everyone to know that I have completed the zerocopy bpf commit. > Please be on the "lookout" for any strange bpf related issues. > > For people that want to test the new zerocopy bpf implementation, a patch > can be found here: > > http://people.freebsd.org/~csjp/pcap.1206364304.diff > > Any comments, patches etc can be sent to Robert Watson (rwatson@) or myself. FYI, right now there is a known issue in which only one of the two BPF buffers can be owned by user processes at a time. As a result, when acking one buffer, it's almost always the case that userspace will enter select() even though another buffer is essentially ready, leading to a system call being generated for each buffer even though that's undesirable. I'm working on some changing allowing both buffers to be owned by userspace at a time, but it will be a couple of weeks before that enters CVS. I believe that the current libpcap patches should keep working with that fine, although of course, we'll see. :-) The bpf.4 documentation is very careful to warn that applications should not assume that there are any invariants about the number of buffers assigned to userspace at a time. Robert N M Watson Computer Laboratory University of Cambridge