On 08 Jul 2014, at 04:55, Henning Brauer <hb-open...@ml.bsws.de> wrote:
> * Franco Fichtner <slash...@gmail.com> [2014-07-06 00:29]: >> Missing SMP support is the fork in the road. The window of opportunity >> seems to be closing. A penny for Henning's thoughts on this... > > my thoughts are only worth pennies? :) It's a kind thing to say, I think. :) > ok, first thought: where's your diff? Not directed at Franco > specifically. See below. > I don't owe anybody anything. OpenBSD hacking is supposed to be fun > for me. That's true. I'm not saying otherwise. > on a technical note - making pf MP is utterly useless if the > underlaying subsystems aren't. pool isn't, mbuf isn't, network stack > isn't - the list is long. Exactly, the underlying cause for this: a lot of complicated subsystems need to be adapted. Some people have this on their ``list of things to do'' as stated a while back, but when there isn't enough incentive to work on this, at least for OpenBSD, it's hard to get started from the outside. The perfect code for the perfect SMP needs to be written and that's not something ``a diff'' from non-developers could easily accomplish. None of this is bad. OpenBSD will always be OpenBSD, no matter what. > And the possible pf MP gains are drasticly overrated anyway. I'm not sure. Maybe that's a stance that fits OpenBSD well, but in networking as a whole that's not applicable. There's a good market for 10G, 40G not so much but it exists (as in drivers make their way into BSDs). Hardware vendors get ready for 100G; I've seen one of those cards and it does reveal a good deal of bottlenecks inside modern kernels. Yes, this requires specific mainstream architectures and PCIe 3.0, which is a small subset of OpenBSD system coverage. I can see that it doesn't make much sense from this point of view. That's where FreeBSD and DragonFly are a better fit. So maybe all that needs to change is the perception of pf(4) ports in other BSDs to be ``very old versions that need to be brought up to date'', because doing so wouldn't solve the most pressing issues we are confronted with pf(4) outside of OpenBSD -- the code itself is stable and the features are well-defined as is. Cheers, Franco
