From owner-svn-src-user@FreeBSD.ORG Mon Nov 26 14:02:33 2012 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAE485F2; Mon, 26 Nov 2012 14:02:32 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 492768FC14; Mon, 26 Nov 2012 14:02:31 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id g24so3419116qab.13 for ; Mon, 26 Nov 2012 06:02:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RIVvLodmB6QEaXqr2fGTY+gCiawOzZJ5abLfoJx1Wyw=; b=neIxgW1nKyPj3xvl+c9kNqvjSSmDuSAGlCjyS+rRADsMqhJ8uIixd5BGXTOJVRt9NC 65A4D9o5MSGXpi8ac7tp0bGPNMnuYyI1yKozgO+b9UUfmXAjmB5RS5Lb0sK8Rv98fegP u9HjbVzPLLXFlW9RL6adjPSpLbBgIH1GCbcBk+xMjnJPujnF/fbr67JazkhyQk3fBNXQ JQMgzqqpIadyV8J5RbIFvrB1H+x6vymgOPMxWJ2+BwQ1EqLVMcjypJhO9nSfrOGxyy/p ePSlmSC2Ck1fWXltXAbpp8UJE1qtRVV8BvDuF99SeWcSDfTm0VM7nxmUJkzo7WNvqrS8 FV7w== MIME-Version: 1.0 Received: by 10.224.215.131 with SMTP id he3mr12336740qab.41.1353938549587; Mon, 26 Nov 2012 06:02:29 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.49.121.163 with HTTP; Mon, 26 Nov 2012 06:02:29 -0800 (PST) In-Reply-To: <50B36A38.7040603@freebsd.org> References: <201211231453.qANErSKF034907@svn.freebsd.org> <20121123152741.GZ84121@FreeBSD.org> <50B36A38.7040603@freebsd.org> Date: Mon, 26 Nov 2012 15:02:29 +0100 X-Google-Sender-Auth: dXSvu12YQ4GFr-uXsFs4K7mRq2g Message-ID: Subject: Re: svn commit: r243458 - in user/andre/tcp_workqueue/sys: net netinet From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Gleb Smirnoff , src-committers@freebsd.org, svn-src-user@freebsd.org X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 14:02:33 -0000 On Mon, Nov 26, 2012 at 2:10 PM, Andre Oppermann wrote: > On 23.11.2012 17:11, Ermal Lu=E7i wrote: > > On Fri, Nov 23, 2012 at 4:27 PM, Gleb Smirnoff > glebius@freebsd.org>> wrote: >> >> Frankly speaking, the fact that the list can't be set directly >> in one sysctl oid: >> >> sysctl net.inet.pfil_in.hooks=3D"pf,**ipfw,ipfilter" >> >> , but can only be set via suppling pointless numeric values to N >> oids looks very poor from perspective of an average user. He might >> think something like "oh, FreeBSD developers were too lazy to parse >> a string", or "they designed an interface not for people but for >> nerds". >> >> Interface must be easier! If you don't like parsing strings in >> kernel, >> then /sbin/pfilctl can be introduced. The utility eventually may gro= w >> more functionality. >> >> I already gave a link to already existing patch for this. >> Not sure why andre@ decided the other way around. >> > > I wanted to have a pre-determined default order of pfil modules > especially with the IPSec pfil hook I've started working on. > That's the reason for the ordering value. This ordering value > has to be carried along somehow. Also I'm no fan of kernel side > parsing, even if there are instances where it can't be avoided. > > So the default pfil hook ordering should lessen the need to reorder > pfil hooks at runtime. > > Would you mind having a pfilctl at Gleb suggested? That way we could > abstract the whole thing away and also gain flexibility in the kernel > implementation for the future. > > Its flexibility added but its just another step people will have to take care when configuring staff. Using sysctl people are familiar with and specifying just strings seems easier when the parsing is simple. With some good documentation that is easier, than having priorities and unsolved problem of what happens at the same priority level! Though the utility has some value if pfil hooks gain ability to be enabled disabled by interface. This can be taken as a micro-optimization to not send every packet over the hooks if people deem its not useful. For example people want ipsec usually only at specific interface(s) and being able to tune the hook at only where needed seems as a feature to me while retaining the default ability of a hook for all packets. In this case the policy tool is needed since the parsing is more complicated. As a scenario in pfSense ipfw is used for captive portal functionality and its needed active only on selected interface(s). I added a flag per interface to control this otherwise the rule sets become unmanageable and introduce measurable overhead. > Another question: In your patch you have a pfil hook disable option > directly in the hook mechanism. What is the reason for that versus > having the pfil consumer unhook itself when not enabled or in use? The use case of it is for disabling ipfw hook at ip level(layer3) while keeping it active for layer2. It seems more natural to control this policy as a pfil interface rather than having pfil consumers having to deal with this kind of policies. > > -- > Andre > > --=20 Ermal