Date: Mon, 26 Nov 2001 17:05:33 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Rajesh P Jain <rpjain_1977@eudoramail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: BPF - Packet Reception Message-ID: <Pine.NEB.3.96L.1011126165908.99169A-100000@fledge.watson.org> In-Reply-To: <FMMCJOMGFAACCAAA@shared1-mail.whowhere.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011126165908.99169A-100000>