From owner-freebsd-ipfw@FreeBSD.ORG Tue Apr 1 04:47:28 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 446ED1065675; Tue, 1 Apr 2008 04:47:28 +0000 (UTC) (envelope-from root@mmu.edu.my) Received: from staff.cyber.mmu.edu.my (staff.cyber.mmu.edu.my [203.106.62.12]) by mx1.freebsd.org (Postfix) with ESMTP id 2F97D8FC16; Tue, 1 Apr 2008 04:47:27 +0000 (UTC) (envelope-from root@mmu.edu.my) Received: by staff.cyber.mmu.edu.my (Postfix, from userid 0) id B7E854D5D43; Tue, 1 Apr 2008 12:28:23 +0800 (MYT) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mmu.edu.my (Postfix) with ESMTP id 4500255E497 for ; Thu, 27 Mar 2008 01:32:48 +0800 (MYT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 670131A7408; Wed, 26 Mar 2008 17:31:25 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 402ED1065677; Wed, 26 Mar 2008 17:31:25 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30E3C1065670 for ; Wed, 26 Mar 2008 17:31:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 1D5008FC23 for ; Wed, 26 Mar 2008 17:31:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 26 Mar 2008 13:17:41 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id A6DEA2D600D; Wed, 26 Mar 2008 10:31:12 -0700 (PDT) Message-ID: <47EA8860.3060709@elischer.org> Date: Wed, 26 Mar 2008 10:31:12 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: vadim_nuclight@mail.ru References: <47E79636.1000909@FreeBSD.org> <47E7EAA8.7020101@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org Cc: freebsd-hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-ipfw@freebsd.org List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2008 04:47:28 -0000 Vadim Goncharov wrote: > Hi Julian Elischer! > > On Mon, 24 Mar 2008 10:53:44 -0700; Julian Elischer wrote about 'Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate': > >> here are some of my ideas for ipfw changes: > >> 1/ redo locking so that packets do not have to get locks on the >> structure... I have several ideas on this > > Currently the main need for locking arises for rule byte/packet counters. The > easiest short-term solution The main need for locking is that the rules can be changed while a processor is traversing the rule set. > >> 2/ allow separate firewalls to be used at different parts of the >> network stack (i.e allow multiple taboe sto co-exist) there are many places that ipfw is currently callable from. ip_input(), ip_output(), ether_demux(), if_brige, ether_output() it would be interesting tobe able to have differnt firewalls in these places (possibly per interface) so that state (e.g. keep_state) can be kept seprately for one place then from another. for example you may not want the result of 'keep state' on an external interface to necessarily affect what happens to packets from the same session when viewed traversing an internal interface. Currently on my more complex ipfw rule sets I break the rule sets out so that packets in different places traverse different rules but it would be nice to have it explicitly supported. > > Umm, could you explain it a little?.. > >> 3/ possibly keeping per CPU stats.. > > How that would be represented to user? it wouldn't.. you'd add them together before presenting them. but every time a packet changes a counter that is shared, there is a chance that it is being altered by another processor, so if you have fine grained locking in ipfw, you really should use atomic adds, which are slow, or accept possibl collisions (which might be ok) but still cause a lot of cross cpu TLB flushing. > _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"