svn commit: r243458 - in user/andre/tcp_workqueue/sys: net netinet

[Ermal Luçi]

On Mon, Nov 26, 2012 at 2:10 PM, Andre Oppermann <andre at freebsd.org> wrote:

> On 23.11.2012 17:11, Ermal Luçi wrote:
>
>  On Fri, Nov 23, 2012 at 4:27 PM, Gleb Smirnoff <glebius at freebsd.org<mailto:
>> glebius at 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="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 grow
>>     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
>
>


-- 
Ermal