* Joris Giovannangeli <jo...@giovannangeli.fr> [2014-07-08 17:47]:
> 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.
i didn't take it as such. Some others might have.

"making it SMP was the faster way (one day of work)" - far off.

updating your pf cannot take that much time. people keep thinking it
is hard due to some of its tentacles. but really, you leave these ptrs
at NULL and be done. can work on providing these hooks later if you
want the associated performance gains.

my offer to help anybody who seriously wants to update pf in fbsd
to a non-ancient version herewith extends to dfly.
help as in answer questions and give advice and the like.

> > it's so obvious... two things needing to access the same data
> > structures cannot run in parallel.

i slightly oversimplified here, of course.

> > 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.

yeah, I know. that is certainly not the stupidest approach ever seen.
wether it is the smartest i'm not certain. not judging here.

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, http://henningbrauer.com/

Reply via email to