From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 00:06:53 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AEC07F88; Mon, 22 Oct 2012 00:06:53 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 789B18FC12; Mon, 22 Oct 2012 00:06:53 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-149-146.hsd1.ca.comcast.net [50.143.149.146]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q9M06kO8078826 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 21 Oct 2012 17:06:46 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <50848E16.6060008@freebsd.org> Date: Sun, 21 Oct 2012 17:06:46 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time References: <508138A4.5030901@FreeBSD.org> In-Reply-To: <508138A4.5030901@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfw@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 00:06:54 -0000 On 10/19/12 4:25 AM, Andrey V. Elsukov wrote: > Hi All, > > Many years ago i have already proposed this feature, but at that time > several people were against, because as they said, it could affect > performance. Now, when we have high speed network adapters, SMP kernel > and network stack, several locks acquired in the path of each packet, > and i have an ability to test this in the lab. > > So, i prepared the patch, that removes IPFIREWALL_FORWARD option from > the kernel and makes this functionality always build-in, but it is > turned off by default and can be enabled via the sysctl(8) variable > net.pfil.forward=1. > > http://people.freebsd.org/~ae/pfil_forward.diff > > Also we have done some tests with the ixia traffic generator connected > via 10G network adapter. Tests have show that there is no visible > difference, and there is no visible performance degradation. > > Any objections? > The number of times I've been brought to a running production system and asked "can you do (mumble) to solve problem 'X' ?", and my answer has been "well we'll have to recompile a kernel to get IPFIREWALL_FORWARD, but then, yes" to be met by "oh but we can't shutdown until XXX days from now due to uptime constraints and rules." is more than I can remember. (mostly back in Vicor days) but in fact, right now I have a system where I want to do this but the original source tree it was built from has been lost so I need to actually rebuild the entire system just to get it. (It's an embedded system) so yes please!