any interest in JIT for bpf and npf_ncode?

[Alexander Nasonov]

Hi,

I've been playing with sljit in the last few days. SLJIT stands for
state-less just-in-time compiler and it supports the following
architectures (from sljit.sf.net):

Intel x86-32
AMD x86-64
ARM (Including ARM-v5, ARM-v7 and Thumb2 instruction sets)
IBM PowerPC-32
IBM PowerPC-64
MIPS-32

I implemented code generation for some bpf instructions. The supported
set is rich enough to measure a performance of a real (well, almost)
bpf program. JIT code is 3-4 times faster on Ubuntu armv7 and 4.5 times
faster on NetBSD-current amd64.

Code is available on github: https://github.com/alnsn/bpfjit

Is there is interest, I can look into porting sljit to the kernel and
adding npf_ncode.

Alex

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alexander Nasonov]

Post by Alexander Nasonov
...
Code is available on github: https://github.com/alnsn/bpfjit
Is there is interest, I can look into porting sljit to the kernel and
adding npf_ncode.

I forgot to add that sljit has a BSD licence.

Below are some references to the prior art.

Linux patch for x86_64:
http://lwn.net/Articles/437981/
http://lwn.net/Articles/437884/

FreeBSD has BPF_JITTER option for i386 and amd64:
http://svnweb.freebsd.org/base?view=revision&revision=153151

Alex

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Lloyd Parkes]

Post by Alexander Nasonov
JIT code is 3-4 times faster on Ubuntu armv7 and 4.5 times
faster on NetBSD-current amd64.

That sounds pretty good and will probably be useful to quite a few people. I know that the WAND group here in NZ wrote their own data capture mechanism because the traditional ones didn't capture data fast enough for them. I don't expect that a JIT will perform as well as a customised hardware and software solution such as WAND's, but these performance improvements might be useful.

I say "might" because nobody really cares if the JIT code is four times faster than the old code. What people care about is how data they can capture, so publishing test results that show more data being captured for less CPU utilisation is good. It would probably help to find a hardware setup that cannot capture traffic at the line rate because then you can show an obvious limitation being made better by the JIT code.

Cheers,
Lloyd


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Zoltan Arnold NAGY]

Hi,

Post by Alexander Nasonov
Hi,
I've been playing with sljit in the last few days. SLJIT stands for
state-less just-in-time compiler and it supports the following
Intel x86-32
AMD x86-64
ARM (Including ARM-v5, ARM-v7 and Thumb2 instruction sets)
IBM PowerPC-32
IBM PowerPC-64
MIPS-32
I implemented code generation for some bpf instructions. The supported
set is rich enough to measure a performance of a real (well, almost)
bpf program. JIT code is 3-4 times faster on Ubuntu armv7 and 4.5 times
faster on NetBSD-current amd64.

Those numbers look great.

Post by Alexander Nasonov
Is there is interest, I can look into porting sljit to the kernel and
adding npf_ncode.

Sure there is. The more performance the better, always ;-)

Zoltan

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mindaugas Rasiukevicius]

Post by Alexander Nasonov
I've been playing with sljit in the last few days. SLJIT stands for
state-less just-in-time compiler and it supports the following
<...>
Is there is interest, I can look into porting sljit to the kernel and
adding npf_ncode.

Why not to port BPF JIT compiler which is available in FreeBSD?

http://docs.freebsd.org/cgi/mid.cgi?200512060258.jB62wCnk084452

I was thinking to support BPF JIT as an alternative to n-code.

[Alexander Nasonov]

Post by Mindaugas Rasiukevicius
Why not to port BPF JIT compiler which is available in FreeBSD?

Because it supports only x86.

SLJIT supports:
Intel x86-32
AMD x86-64
ARM (Including ARM-v5, ARM-v7 and Thumb2 instruction sets)
IBM PowerPC-32
IBM PowerPC-64
MIPS-32

Alex

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Alexander Nasonov

Post by Mindaugas Rasiukevicius
Why not to port BPF JIT compiler which is available in FreeBSD?

Because it supports only x86.
Intel x86-32
AMD x86-64
ARM (Including ARM-v5, ARM-v7 and Thumb2 instruction sets)
IBM PowerPC-32
IBM PowerPC-64
MIPS-32

What are the plans to support other architectures, such as SPARC?

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alexander Nasonov]

Post by Darren Reed
What are the plans to support other architectures, such as SPARC?

I asked sljit author Zoltán this question and he replied that SPARC
support would be good but he neither have time nor hardware to work
on it at the moment.

Alex

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Alexander Nasonov
...
Code is available on github: https://github.com/alnsn/bpfjit
Is there is interest, I can look into porting sljit to the kernel and
adding npf_ncode.

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 is for the above reason that I've never considered using BPF
instructions in IPFilter
rules as something more than experimental:

# To enable rules to be written with BPF syntax, uncomment these two lines.
#
# WARNING: If you're building a commercial product based on IPFilter, using
# this options *may* infringe at least one patent held by
CheckPoint
# (5,606,668.)
#
#IPFBPF=-DIPFILTER_BPF -I/usr/local/include
#LIBBPF=-L/usr/local/lib -lpcap

... more than the above I cannot speculate on as I've not researched it
any further.

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alexander Nasonov]

Post by Darren Reed
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?

Post by Darren Reed
#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?

Thanks,
Alex

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven Bellovin]

Post by Alexander Nasonov

Post by Darren Reed
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?

If it's 5,606,668 -- the only 1995-or-earlier patent assigned to Checkpoint
that I found in a *very* quick search -- no, it has about two more years left.
It was filed on December 15, 1993, and (in the U.S.) lasts for 20 years from
filing.


--Steve Bellovin, https://www.cs.columbia.edu/~smb






--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Alexander Nasonov

Post by Darren Reed
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?

Post by Darren Reed
#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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alexander Nasonov]

Hi,

Recent commit by rmind@ prompted me to give update on my stuff.

I mostly finished NetBSD integration about a month ago but due to a lack
of time I could neither finish my work nor report my progress on the list.

I introduced a new BPFJIT option to the kernel and added two new
kernel modules: sljit and bpfjit.

sljit.kmod is 34K on amd64
bpfjit.kmod is 12K on amd64

If you compile the kernel with BPFJIT option, you can start running
bpfjit code for new filters when you load bpfjit modules. There is
no sysctl option to turn it on or off.

The modules are always compiled regardless of BPFJIT option on supported
arches. At the moment it's only amd64 because I can't test it on other
arches but it should also work on arm (I tested my stuff in usermode on
armv7l linux), i386, mips and ppc.

I wrote many micro-tests for usermode but they don't use ATF. Converting
them to ATF should not be difficult.

Alex

Post by Alexander Nasonov
Hi,
I've been playing with sljit in the last few days. SLJIT stands for
state-less just-in-time compiler and it supports the following
Intel x86-32
AMD x86-64
ARM (Including ARM-v5, ARM-v7 and Thumb2 instruction sets)
IBM PowerPC-32
IBM PowerPC-64
MIPS-32
I implemented code generation for some bpf instructions. The supported
set is rich enough to measure a performance of a real (well, almost)
bpf program. JIT code is 3-4 times faster on Ubuntu armv7 and 4.5 times
faster on NetBSD-current amd64.
Code is available on github: https://github.com/alnsn/bpfjit
Is there is interest, I can look into porting sljit to the kernel and
adding npf_ncode.
Alex