Date: Thu, 6 Sep 2012 10:46:40 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Ermal Lu?i <eri@FreeBSD.org> Cc: pf@FreeBSD.org Subject: Re: [HEADS UP] merging projects/pf into head Message-ID: <20120906064640.GL15915@glebius.int.ru> In-Reply-To: <CAPBZQG0a4WVB4W4OwF3CAJH-G4DTDan-Nz1HR1SFAgFOfe%2Ba=Q@mail.gmail.com> References: <20120905115140.GF15915@FreeBSD.org> <50476187.8000303@gibfest.dk> <20120905183607.GI15915@glebius.int.ru> <CAPBZQG0a4WVB4W4OwF3CAJH-G4DTDan-Nz1HR1SFAgFOfe%2Ba=Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ermal, On Wed, Sep 05, 2012 at 10:02:17PM +0200, Ermal Lu?i wrote: E> as already shared with you the opinion the new 're-arrangement' of E> data structure together with new syntax E> is more helpful to SMP in general, so complementary to this work. E> As the person who has done most of the work on last import of pf form E> OpenBSD, so you E> can say knowledgeable about the internals of it, will still recommend E> the new syntax. E> - No more multiple rulesets is the single biggest reason. The new or old syntax is completely orthogonal to SMP. The SMP scalability is all about the storage, not about rulesets. I have looked into newer OpenBSD and their new pf modifies rulesets from the forwarding path more then pf-4.5 did, thus it is not "more helpful to SMP in general", but the opposite. E> > Bulk imports are no longer possible (unless one wants to ruin all my work). E> > We have had some pain with bulk imports. The last one, for example, have E> > broken pfsync completely. E> > E> > First, imports were made with focus on minimizing diff to OpenBSD. Code was E> > made compilable on FreeBSD and somehow working. But the operating systems have E> > diverged very much sincle last 15 years, and thus quality porting requires more E> > than just make it compile. For example, OpenBSD runs network stack under splnet(9). E> > They can run ip_output() anywhere in the network stack (except of ip_output() E> > itself, heh). We can't since that would make lock order reversals. This was just E> > one example, but believe me, there are much more. All this peculiarity were worked E> > out correctly in my branch. So, this branch is not about SMP scalability only, E> > this is a better port of pf to FreeBSD. E> > E> E> This is more a issue of FreeBSD rather than OpenBSD perse. E> pf(4) has survived with code sharing so far quite well and i have seen E> nothing in your project branch that does a better job to this. I'd prefer not survival for the pf, but robustness and performance :) Let me number the most important things in my project branch that do better job: - safely decoupled stack when sending generated packets: pf_send_tcp(), pf_send_icmp() - safely decoupled stack when sending pfsync(4) deferrals - safely removed the "pfugidhack" - provided correct locking in pf_route(), pf_route6() - offloaded the "flush" functionality to a taskqueue - removed unsafe lock dropping before malloc(9), or unsafe entering malloc(M_WAITOK) with locks held - removed unsafe lock dropping before copyin(9)/copyout(9) E> > Second, the imported code (what we have now in head) is polluted with zillions of E> > ifdefs and is difficultly readable even by the person who wrote it. Any other E> > developer runs away in fear when he faces that. This ends up with no one willing E> > to fix open problem reports. We have now 53 PR assigned to freebsd-pf@. They are E> > rotting and no one takes them. Most of these PRs can't be forwarded to OpenBSD, E> > since they are specific to our port (yep, port has problems - see above paragraph). E> > E> This is not an argument but just whining. E> Too much code in FreeBSD has that. "Too much code in FreeBSD has that" isn't an excuse either an argument. E> > >From my point of view the state of pf in FreeBSD is (was) a dead end. We don't E> > modify it, since it isn't ours, but we hope that new bulk import would fix problems. E> > E> > I hope that new state of pf in FreeBSD would attract more developers to it. I E> > have nothing against with cherry-picking new features from OpenBSD (but E> > taking into account new multithreaded design). I have nothing against completely E> > new features. I'd appreciate any attempt to reduce number of PRs assigned to E> > freebsd-pf@. E> > E> > T> Currently the common "pf-ecosystem" that we've always more-or-less E> > T> shared with OpenBSD seems to be crumbling. If we are going to continue E> > T> along our own "branch" of pf, with old syntax and SMP support, and who E> > T> knows what else in the future, should we consider renaming it to avoid E> > T> having two similar-but-not-identical firewalls with the same name ? E> > E> > May be it is worth renaming, I have nothing against this. But I don't E> > think it is already time to rename right now. Now the only rewritten part E> > is keys/states storage, all other code is shared with OpenBSD, however E> > touched a lot. E> E> I would suggest this, and always would be for this, E> since too much expected internal behavior has changed internally with E> what i have seen on your project branch. E> E> People can test the renamed version and have an option to roll back to E> the previous one. E> After all you are saying that its not pf yourself. I won't keep OpenBSD-pf and FreeBSD-pf in parallel in FreeBSD. The OpenBSD-pf port have proved to be poorly maintained. After last import that was made by you, at least the following regressions were introduced: - enabling pfsync immediately panics - kldunload pf.ko immediately panics Hey, these aren't a difficult to catch bugs, that require special setup or weeks of catching a race condition. This is basic functionality, and panics are evidence that code wasn't tested properly. Okay, we all ain't saints, and people do errors. But why wasn't you promptly fixing these errors? You just dropped many Kb of code into SVN (via bz@) and then disappeared. Have you closed at least on PR in GNATS? If you (or anyone else) really loves vanilla pf from OpenBSD, and if for you word "new" implies "better" then you should just install OpenBSD and enjoy the newest pf available in the world. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120906064640.GL15915>