From owner-freebsd-hackers Mon Nov 26 14: 5:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 9B1C837B416 for ; Mon, 26 Nov 2001 14:05:47 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fAQM5Yi99425; Mon, 26 Nov 2001 17:05:34 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 26 Nov 2001 17:05:33 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Rajesh P Jain Cc: freebsd-hackers@freebsd.org Subject: Re: BPF - Packet Reception In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 26 Nov 2001, Rajesh P Jain wrote: > We are trying to use BPF (Packet Filter) pseduo device to send > and receive the packets. > Even if there is a slight delay (Some processing has to be done > on the read packet) between the issuing of 'read' call, so many packets > are getting dropped. > Is there a way to attach a callback function to the opened device, > so that on a packet arrival, this function is being called. > We polling the device is always risky thing as we may loose some > packet. > Any help on this would be very much appreciated. Thanks and > regards, -Raj There are a number of things that can be done to improve BPF's behavior under high volume, including setting a larger in-kernel buffer for BPF (using BIOCSBLEN), as well as implementing the equivilent of interupt coallescing when delivering packets to userland, through the use of a timeout (BIOCSRTIMEOUT, BIOCIMMEDIATE), which can increase throughput. While BPF is not able to handle extremely high packet rates, due to it performing memory copies and simple virtual machine execution, I've quite successfully used it to do userland packet forwarding (read, process, send) in the 100mbps range on moderately equipped machines. Depending on the nature of the packets you're capturing, optimizing your BPF code, or feeding it code that matches more specifically, can also impact performance. The performance of BPF is often directly associated with the amount of userland context switching going on: for example, running my BPF-based packet forwarding program at the same time as tcpdump would easily halve the throughput by making the number of context switches proportional to the number of packets delivered. A single process performing BPF operations will perform *much* better on an unloaded machine. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message