> 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 [email protected] _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[email protected]"
