Re: any interest in JIT for bpf and npf_ncode?

[Darren Reed <darrenr%netbsd.org@localhost>]

On 4/01/2012 10:16 PM, Alexander Nasonov wrote:
> Darren Reed wrote:
>> This is probably quite important for NPF as it moves NPF away from
>> using the byte
>> code method. This is important for anyone thinking of hardware
>> devices using NPF
>> as NPF seems dangerously close to what Checkpoint patented for
>> Firewall-1 back
>> in 1995.
> 
> It moves NPF to another parent minefield I think ;-)
> The patent you mentioned is quite old. Hasn't it expired already?
> 
>> #IPFBPF=-DIPFILTER_BPF -I/usr/local/include
>> #LIBBPF=-L/usr/local/lib -lpcap
> 
> This is interesting. Can this feature be used to test a firewall
> throughput of interpreted vs compiled rules?

I suppose it could.

If you want to do compiled rules, you would build IPFilter
using IPFILTER_COMPILED defined so that you can do:
# ipf -n -cc -f /etc/ipf.conf

and generate .c and .h files that are the rules. The resulting
code is then loaded into IPFilter and it effectively executes
one rule per rule group, although "ipfstat -io" will more or
less behave as you would expect. Understandably, performance is
significantly better when using the above to generate c code
that represents the rules and can be built into the kernel.

It has been a long time since I've tested that so I'm not sure
how bug-free it still is.

I think the key to better use of things like n-code and BPF in
firewall rules is to do more complex or a longer set of checks
than just comparing a small number of fields. For example,
having "(src host a or src host b) and (dst port c)". Otherwise,
just having "src host a and dst port c" in each rule is not a
significant enough win when comparing using structures vs byte
code.

Darren