Date: Tue, 02 Apr 2019 15:22:45 +0200 From: "Kristof Provost" <kp@FreeBSD.org> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: rgrimes@FreeBSD.org, "Andrey V. Elsukov" <bu7cher@yandex.ru>, "Mateusz Guzik" <mjguzik@gmail.com>, freebsd-pf@FreeBSD.org Subject: Re: svn commit: r345760 - in head: contrib/pf sys/netpfil/pf sbin/pfctl Message-ID: <B9AD4311-A3AC-4754-8982-A6809AEE4541@FreeBSD.org> In-Reply-To: <201904012106.x31L66wC017378@gndrsh.dnsmgr.net> References: <201904012106.x31L66wC017378@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1 Apr 2019, at 23:06, Rodney W. Grimes wrote: >> On 1 Apr 2019, at 18:47, Rodney W. Grimes wrote: >> Those are: >> >> - scalability > 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? > It might be useful to help OpenBSD do their locking work first. Or at least talk to them and ask what the state of it is. I had a very quick look at their current tree yesterday evening, and found that while they’re working on the locking there’s a long way left to go. We can’t just take our existing locking work and apply it to OpenBSD’s tree. There are too many differences for that to be viable. One example is the state lookup. In our code that’s a hash table, and we lock the individual hash rows. In OpenBSD’s tree it’s a red-black tree, which can’t be trivially split up as we’ve done. >> 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. > There are feature differences too, yes, but the syntax is the most visible point. We can easily add extensions to the pf.conf language without worrying about breaking existing configurations. That’s not the case with the syntax changes. I’ve already brought over a couple of smaller features. That’s relatively straightforward. (Hence also my question about what users actually want. If that’s smaller features it’s a *much* easier and less invasive process.) >> 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. > Probably, yes. With the usual caveats and disclaimers. >> >> 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 :-) Don’t make me roll up the newspaper. We’re not adding firewalls. Or I’m not, in any case. > 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. > It’d likely also be a helpful step in adding the locking to the OpenBSD code. I’m not sufficiently familiar with OpenBSD to know if they’ve got equivalents to our lockstats/pmcstat/dtrace tools, and those are very nice to have for locking work. Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B9AD4311-A3AC-4754-8982-A6809AEE4541>