svn commit: r345760 - in head: contrib/pf sys/netpfil/pf sbin/pfctl

[Rodney W. Grimes]

> On 1 Apr 2019, at 18:47, Rodney W. Grimes wrote:
> > I know for a fact that there is desire, with financials avaliable,
> > to get our code updated.  I do not think there is any specific
> > criteria desired, other than moved closer to the OpenBSD version.
> >
> It?s a good goal, but there are three major issues along the way to 
> importing the latest OpenBSD version. (And I?m sure a whole bunch of 
> smaller ones.)

This is a grand start, thank you for providing this input to the
process.

> Those are:
> 
>   - scalability
>   - syntax
>   - vimage
> 
> The scalability issue is the obvious difference: OpenBSD?s pf is still 
> very much single-core oriented, whereas the FreeBSD pf version can cope 
> with multiple cores (somewhat) and is significantly faster on multicore 
> hardware. Our version is by no means perfect, but it?s much faster 
> than OpenBSD?s version. Much of the imperfections we have now is there 
> because pf was designed in a giant locked kernel in the first place. 
> Multi-core scalability was not part of its original design.
> 
> Adopting OpenBSDs pf would mean redoing all of the locking work Gleb did 
> years ago. Given the differences in OpenBSD?s pf (e.g. they keep 
> states in a tree, not a hash table) it?s not a matter of replaying the 
> previous work on a new pf version. This is a from the ground up 
> introduction of fine grained locking in a code base that assumes a 
> single giant lock. As I understand it the OpenBSD people are working on 
> the problem as well, but I?ve not seen any diffs yet. If they?ve 
> made significant progress we may be able to base our work on theirs.
> I don?t think it?d be acceptable to not have this, as it?d mean a 
> very large performance regression.
> 
> For reference, before I did the pfsync work we essentially had a 
> single-threaded pf when pfsync was enabled. On my test hardware this 
> meant a throughput of ~1.1Mpps, rather than the ~3.9Mpps without pfsync. 
> I?d expect OpenBSDs pf to perform at around that ~1.1Mpps number 
> without locking work.

The project funding source is OS agnostic, would it help if the
OpenBSD pf implementation was redone in a way that it had fine
grained locking.  Would it be possible to apply Gleb's work as
a upstreaming operation to get this work in both implementations?

> The second issue is one of syntax, and that?s what I assume is the 
> main reason people want OpenBSDs pf. We?re still on an older iteration 
> of the pf syntax, but changing that would inevitably mean breaking old 
> configurations. That might be acceptable on a major version update (i.e. 
> going into 13), but would mean the new work could never be backported.
> That?s probably the only way forward though. I?m playing with 
> importing the ?match? keyword and not breaking the ?scrub? 
> syntax at the same time, but it?s a non-trivial problem, and that?s 
> only one of the steps along the way.

Isnt there more than just syntax?  I thought OpenBSD pf has features
that are not present in FreeBSD's pf implementation.

> Finally there?s vimage. That?s a FreeBSD-only feature, so naturally 
> OpenBSDs pf is not aware of this. I expect that to be relatively easy to 
> add back in, but it?s another obstacle. As vimage is what lets us have 
> the pf tests we?ve got now I?d be very reluctant to let it go. 
> It?s a supported feature in 12.0, so users will start to rely on it as 
> well.
> 
> TL;DR: It?s possible, but *hard*. Expect is to be many person-months 
> of effort, and there?s no way it?s going to be a smooth ride.

So your quantifying this at man months and not man years,
that helps a bunch, that is clearly within the scope of
the funding.

> 
> One thing I?ve thought of trying, and that might be an interesting 
> stepping stone, is to create a port (/usr/ports/net/opf or whatever) of 
> OpenBSD?s pf. In that version it?d be acceptable to not fix any of 
> the above issues. It?d still give users to option of getting the new 
> syntax. I?d expect this to be a relatively straightforward exercise.
> In principle there?s nothing to stop us from doing that same work in 
> base, but we?re **NOT** going to import a fourth firewall. We?re 
> just not.

But 4, its nice, its a power of 2, infact it is the second power of
2, such nice round numbers :-)  I do like the idea of a first
implementation of pf as a port, that being a fast path to update it,
but would not want that as a long run solution.  

> Regards,
> Kristof
-- 
Rod Grimes                                                 rgrimes at freebsd.org