From owner-freebsd-net@FreeBSD.ORG  Fri Mar  2 19:03:09 2012
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B9C33106564A
	for <net@freebsd.org>; Fri,  2 Mar 2012 19:03:09 +0000 (UTC)
	(envelope-from luigi@onelab2.iet.unipi.it)
Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238])
	by mx1.freebsd.org (Postfix) with ESMTP id 387E88FC08
	for <net@freebsd.org>; Fri,  2 Mar 2012 19:03:09 +0000 (UTC)
Received: by onelab2.iet.unipi.it (Postfix, from userid 275)
	id 87C387300A; Fri,  2 Mar 2012 20:21:26 +0100 (CET)
Date: Fri, 2 Mar 2012 20:21:26 +0100
From: Luigi Rizzo <rizzo@iet.unipi.it>
To: net@freebsd.org
Message-ID: <20120302192126.GA46358@onelab2.iet.unipi.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Cc: 
Subject: userspace version of ipfw kernel module
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Mar 2012 19:03:09 -0000

I have written some glue code that lets you build a userspace version
of the kernel-side of ipfw (and dummynet), for the following purposes:

1. performance testing. You can run the ipfw_chk() code in a tight loop
   and actually measure its runtime, instead of being dependent
   on input traffic and device drivers and other overheads

2. (eventually) build userspace versions of the firewall on top of
   netmap or other accelerated I/O frameworks.

The tarball is at
	http://info.iet.unipi.it/~luigi/netmap/20120302-ipfw-user.tgz

The client side (ipfw/ipfw) talks to the former-kernel side (dummynet/ipfw)
via a tcp socket (localhost:5555) so you can inject rules etc.

To start a fake infinite traffic source do a
	telnet localhost 5556
and press some chars before aborting the connection

Then you can still check how fast the filter processes rules
by runinng something like this

	sh -c "while true; ipfw/ipfw show; ipfw/ipfw zero; sleep 1; done"

I believe a similar approach could be useful for 'pf' too.
And the glue code is probably easy to recycle -- in the tarball,
sbin/ipfw and sys/netinet/ipfw are identical (except perhaps
for a few lines) to the version in head.

enjoy
luigi