Hi, Posting such a topic in such a list might probably sound a bit aggressive, but this patch should not be misinterpreted. I think it's clear to everybody that it would be great to update pf in dragonfly, but that's a lot of work and nobody is working on this. This patch followed a complaint on the mailing list about the slowness of pf on dragonfly, and I guess that making it SMP was the faster way (one day of work) to solve this issue. I don't think that anybody ever claimed that pf had become faster or better on dfly than on openbsd, or that openBSD is lagging behind.
That being said, i subscribed to this list to reply to your last assertion. > it's so obvious... two things needing to access the same data > structures cannot run in parallel. > packet filters CAN profit from MP, but it is way less than people keep > thinking. This is obvious indeed, that's why the goal of this patch is to avoid the need to access the same data structures. This is due to the design of the dragonfly network stack. Packets are hashed, for instance with tcp they are hashed using the two tuples (host, port) for destination and origin, and they are dispatched to a fixed cpu according to this hash. The packet is then handled by this cpu, and the thread is pinned to this cpu. Things are more complex in practice due to hardware hashes, forwarding and other things i'm not an expert on the topic, but basically, it reduce the amount of sharing needed. You can take advantage of this design to make a packet filtering almost lockless. Indeed, you only need to access the local state for a lot of rules, and since the state structure is owned by the current cpu, you don't need any lock. (for nat/rdr or stateful firewalling, things are a bit less easy). In practice, this work as a real impact on my router, hence I really think that's nice to have, even if obviously having an up to date pf or good ipv6 support is more important (and a lot harder to do). Regards, joris
