From owner-svn-src-head@freebsd.org Wed Apr 5 12:05:02 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FB64D2FE6D; Wed, 5 Apr 2017 12:05:02 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FD516DC; Wed, 5 Apr 2017 12:05:02 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8E61620BD6; Wed, 5 Apr 2017 08:05:00 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 05 Apr 2017 08:05:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=rYqF8cWiwkH/bvzqja PtdkYG1pqUxtuLdJzdVFG0LpM=; b=DpGdHHkCQkQVLuQKIA8ATl2nMZTi+mts/a Po8O4X4C/bzX/PCSuHrR6fFKE7cl7UO0zwmCmYlRYUdTKNpJjjwiUskdafqEkKwY dEKFzL2B2iXBoz6pDNJv8u6dXTzAahQFalwizB4MoS9TX1JhxLcB6SH5i55AvDX6 RPcyIgzCV9DxAQJCYxkAKJRaE2pltgxFJA95PQqFlh9H8WrrytBICWAhjNvI3HQn 2A7af+XeaAn03EvOVwN0ngtnNpr8jAYl82hYh2maWO++24+e/mOGTqHFRv8B3Cm/ UESfnQUKec0F3U/ujMvCkRTsK0KsjnuykxeHesxIwi/E7MigPXXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=rYqF8cWiwkH/bvzqjaPtdkYG1pqUxtuLdJzdVFG0LpM=; b=f2sinEGa 3cFDnmg1rBeP7+g2eH1s1CrpWNPbJav3lbriD9TYU1Srf0vMknD1yY+lfm+Alrn3 vp3aRNLYhmt+T5uYN1iTP8ZQXj/NCGx3aJipC8uQ3Et3oB06LmNuHKoDiL+F8BJ1 RiBMAuicV7v1Q0zePgUsityBkwJOvKEkAJBsvsorQQ8pSVGWq7ZINQHnYCWsVSop NdevjQ+WiF8ye9CjX5EFJZwir8uK/7us5uydTPpGAebEPpsOZiix33Umx76yP7oY kjgJaQzphWvOCXQmf3137a7/YkplSMbx8a37ha8SYgobuaY+JLrlWmjkC1+MTwMr NLYIICdZ/294Pw== X-ME-Sender: X-Sasl-enc: J0ve3Keu/+sFizuOMB1581bNWETma/oZzzgcbv+klnoJ 1491393900 Received: from [192.168.1.88] (cpc96954-walt26-2-0-cust843.13-2.cable.virginm.net [82.31.91.76]) by mail.messagingengine.com (Postfix) with ESMTPA id B3CC72469B; Wed, 5 Apr 2017 08:04:59 -0400 (EDT) Subject: Re: svn commit: r316435 - in head: sbin/ipfw sys/conf sys/modules sys/modules/ipfw_pmod sys/netpfil/ipfw/pmod To: Julian Elischer , "Andrey V. Elsukov" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201704030307.v3337mfs039014@repo.freebsd.org> <2fb0e146-8486-09c3-0c44-75c71a74fc2f@freebsd.org> From: Bruce Simpson Message-ID: Date: Wed, 5 Apr 2017 13:04:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2fb0e146-8486-09c3-0c44-75c71a74fc2f@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 12:05:02 -0000 On 03/04/17 15:12, Julian Elischer wrote: > On 3/4/17 11:07 am, Andrey V. Elsukov wrote: >> Author: ae >> Date: Mon Apr 3 03:07:48 2017 >> New Revision: 316435 >> URL: https://svnweb.freebsd.org/changeset/base/316435 > > it was always my intention to hook netgraph modules into ipfw in this way In my humble opinion, in an ideal world, everything warrants a rethink - in terms of "abstract forwarding elements". This is how a lot of the newer integrated routing/switching hardware seems to behave; designs like the FM6000, Juniper's Trio, and so on. For now, we've got several bodies of firewall code available in the FreeBSD base system. The MSS tweak is much appreciated; it makes DSL and Cable access more usable for many. But I appreciate the sentiment of taking what is - on the face of it - a simple network protocol transformation at a FreeBSD hop, as something which really, we'd ideally have a common way of expressing. I struggle to keep track of all of this development, personally. It would be great if we could take the best from all of them, incorporate scalability for LRO and so on, and hybrid forwarding chips, or other offload stack approach, in the same code base somehow. It's worth a trip down to the 1.4Tbit/s Alien Superchannel to see what I'm getting at. Multi-100GBE into 1U is a reality now.