From owner-freebsd-arch@FreeBSD.ORG Sat Aug 20 14:21:36 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0669210656D8; Sat, 20 Aug 2011 14:21:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D75FE8FC12; Sat, 20 Aug 2011 14:21:35 +0000 (UTC) Received: from [192.168.2.124] (host81-151-180-177.range81-151.btcentralplus.com [81.151.180.177]) by cyrus.watson.org (Postfix) with ESMTPSA id ABBC646B0A; Sat, 20 Aug 2011 10:21:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <5299.1313849459@critter.freebsd.dk> Date: Sat, 20 Aug 2011 15:21:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5299.1313849459@critter.freebsd.dk> To: "Poul-Henning Kamp" X-Mailer: Apple Mail (2.1084) Cc: Lev Serebryakov , freebsd-arch@FreeBSD.org Subject: Re: 10gbps scalability (was: Re: FreeBSD problems and preliminary ways to solve) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 14:21:36 -0000 On 20 Aug 2011, at 15:10, Poul-Henning Kamp wrote: > In message , = Robert Watso > n writes: >=20 >> Part of the key here will be reworking things like ipfw(4)=20 >=20 > Here is how to do it: >=20 > Compile IPFW rules to C-code, compile C-code to KLD, load KLD and hook > the firewall rules. >=20 > If the C-code is designed smartly, the C-compiler can optimize to > insanely efficient code. >=20 > The same semantics as today can be preserved with respect to counters > and dynamic addition/removal of rules, with a little bit of creative > thinking about data structures. >=20 > Somebody[tm] did that long ago, but never contributed the patches back > once The Mgt[tm] realized what performance we were talking about. I'm actually slightly less concerned about this aspect of it, although = some sort of JIT/etc, perhaps grounded in LLVM, would make sense. I'm = more concerned with the management of firewall state in the presence of = multiple network queues and SMP. We should be able to build = substantially on the approaches we've been using higher in the network = stack to align NIC-level work distribution with network stack processing = and application process affinity. (These ideas are still coming to = maturity, but there's useful stuff to be found there.) Robert=