Re: Dragonflybsd's pf concurrent instead of single-threaded

[Loïc BLOT]

Thanks for the precisions :).
And no problem i you laugh because of me :p
--
Best regards,
Loïc BLOT,
UNIX systems, security and network engineer
http://www.unix-experience.fr



Le mardi 08 juillet 2014 à 11:03 +0200, Henning Brauer a écrit :
> * InterNetX - Robert Garrett  [2014-07-08
09:42]:
> > Uprading pf with [dfly's] set of changes to support [dfly's] locking
> > mechanisms, is a seriously non trivial exercise.
>
> and 100% wasted as done.
>
> starting off an old, ancient, pf, which is roughly 4 times slower than
> todays (but hey, you can throw cores at it, make intel & the power
> companies even richer, increase pollution, and whatnot), and making
> sure we can never take these changes back even if we wanted to.
>
> how bright!

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Henning Brauer]

* Joris Giovannangeli  [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/

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Joris Giovannangeli]

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

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Henning Brauer]

* sven falempin  [2014-07-08 14:16]:
> On Mon, Jul 7, 2014 at 11:55 PM, Henning Brauer  wrote:
> > * Franco Fichtner  [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? :)
> >
> > ok, first thought: where's your diff? Not directed at Franco
> > specifically.
> >
> > I don't owe anybody anything. OpenBSD hacking is supposed to be fun
> > for me.
> >
> > 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.
> 
> Where to start ? prediction tends to show the base speed of processing
> unit is reaching a maximum and multicores is the next things.
> 
> The network stack ?
> mbuf ?

pool(9) - underway/getting there.
mbuf

then it gets "interesting".

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

Re: Dragonflybsd's pf concurrent instead of single-threaded

[sven falempin]

On Mon, Jul 7, 2014 at 11:55 PM, Henning Brauer  wrote:
> * Franco Fichtner  [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? :)
>
> ok, first thought: where's your diff? Not directed at Franco
> specifically.
>
> I don't owe anybody anything. OpenBSD hacking is supposed to be fun
> for me.
>
> 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.

Where to start ? prediction tends to show the base speed of processing
unit is reaching a maximum and multicores is the next things.

The network stack ?
mbuf ?


>
> And the possible pf MP gains are drasticly overrated anyway.
>
> --
> 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/
>



-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Paolo Aglialoro]

> Lucky, I've been asked to leave this mailing list so you don't have
> to bother.  Good luck.

This is quite sad: polite confrontation is always good means of progress,
whatever the topics.

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Henning Brauer]

* Franco Fichtner  [2014-07-08 11:20]:
> On 08 Jul 2014, at 09:58, Henning Brauer  wrote:
> > this has NOTHING to do with the problem or the question at hand.
> So then what has it to do with?  You tell me I missed the obvious
> but don't provide your arguments.

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. 

> Lucky, I've been asked to leave this mailing list

not by me...

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

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Franco Fichtner]

On 08 Jul 2014, at 09:58, Henning Brauer  wrote:

> this has NOTHING to do with the problem or the question at hand.

So then what has it to do with?  You tell me I missed the obvious
but don't provide your arguments.

Lucky, I've been asked to leave this mailing list so you don't have
to bother.  Good luck.


Cheers,
Franco

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Henning Brauer]

* InterNetX - Robert Garrett  [2014-07-08 09:42]:
> Uprading pf with [dfly's] set of changes to support [dfly's] locking
> mechanisms, is a seriously non trivial exercise.

and 100% wasted as done.

starting off an old, ancient, pf, which is roughly 4 times slower than
todays (but hey, you can throw cores at it, make intel & the power
companies even richer, increase pollution, and whatnot), and making
sure we can never take these changes back even if we wanted to.

how bright!

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

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Henning Brauer]

* Franco Fichtner  [2014-07-08 10:48]:
> On 08 Jul 2014, at 04:55, Henning Brauer  wrote:
> > 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.

sigh.
it is obvious you have very little idea on what you're talking about
here.

this has NOTHING to do with the problem or the question at hand.

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

guess the fact that the pf code in OpenBSD is roughly 4 times as fast
as elsewhere doesn't matter. after all, it's not about the results but
shiny labels, right? 

pah humbug.

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

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Franco Fichtner]

On 06 Jul 2014, at 01:01, Predrag Punosevac  wrote:

> The rumors are that npf is a vaporware.

npf(4) is a chain of clever data structures.  How well that translates
to the actual requirements of the networking domain I can't see.

> DragonFly community is tiny.

You mean alive and well.  That's all that matters to keep us going.  ;)

> tiny that in-spite of HAMMER I could not use DragonFly on my production
> file servers because it lacks LDAP support let alone NFSv4.

Let's talk about this off-list.

> FreeBSD always had its own genuine firewall solution IPFW.

I haven't seen much use of ipfw(4) in the last years, and what it
is (still) being used for is not capable of scaling up anymore.  The
clear preference seems to be pf(4) these days.

> That being said OpenBSD project has its own pace which has never being
> dictated by "current fashion trends" or a noise made by people like me
> who don't contribute the code.

I appreciate the steady course as well, although I would not label
SMP as a ``current fashion trend'' that's likely to disappear again.


Cheers,
Franco

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Franco Fichtner]

On 08 Jul 2014, at 04:55, Henning Brauer  wrote:

> * Franco Fichtner  [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

Re: Dragonflybsd's pf concurrent instead of single-threaded

[InterNetX - Robert Garrett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

you will find ldap support within dfly -current..

and no you will not find nfsv4

rg

On 07/06/2014 02:16 AM, Brad Smith wrote:
> On 05/07/14 8:01 PM, Predrag Punosevac wrote:
>> Franco Fichtner write:
>>
 I have immense respect for Matt as a user of his code since Amiga C
 compiler. I probably speak for lots of people both in OpenBSD and
 DragonFly camp if I say that I would prefer him to finish HAMMER2 and
 leave concurrent threading in PF to Henning.
>>
>>> Talks about this date back at least two years.  These days NetBSD is
>>> doing npf(4), and FreeBSD and DragonFly moved on to implement their
>>> own SMP support.
>>>
>>
>> The rumors are that npf is a vaporware.  DragonFly community is tiny. So
>> tiny that in-spite of HAMMER I could not use DragonFly on my production
>> file servers because it lacks LDAP support let alone NFSv4. FreeBSD
>> always had its own genuine firewall solution IPFW. IPFW is so good that
>> inspired even a better tool called iptables. Some people unfortunately
>> didn't buy it. OS X switched from IPFW to PF couple releases ago.
>>
>>> 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...
>>>
>>
>> I would say it is about a time. PF has never meant to be portable. A
>> quick look on the version of PF in use in other BSDs is quite revealing.
>> That being said OpenBSD project has its own pace which has never being
>> dictated by "current fashion trends" or a noise made by people like me
>> who don't contribute the code. Thanks God for that!
> 
> What is the point of your posts other than filling peoples mail
> boxes with useless bits?
> 
> 


Mit freundlichen Grüßen

Robert Garrett
Senior System Engineer
Technical Projects & Solutions
- --
InterNetX GmbH
Maximilianstr. 6
93047 Regensburg
Germany

Tel. +49 941 59559-480
Fax  +49 941 59559-245

www.internetx.com
www.facebook.com/InterNetX
www.twitter.com/InterNetX

Geschäftsführer/CEO: Thomas Mörz
Amtsgericht Regensburg, HRB 7142
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTu6IeAAoJEMrvovfl62c811cH/i3t6PExfQkgKuBuat72rTVJ
tpKaeHKK1vkV9fRhaljJyRZIceDAnJiBot7FZgVEVmteANzZffMK0inumNJx1nCf
0iC6L+6ypG6bqkATpD7hz2Q4vA0OZopeQG2njvTGwl7Njaq5MfVcEVCdRG13lj2m
HTrksidCy7r5P48BdO9YXnagw9d2wAce4LhuKn5D7LFWYfSz/H/dt1ViveppNsuT
fOPP91GItQ2R3Jnqqf4oJJBSW61ea4dQ5VfuerXv2HOCm9s+ASBBdCaqwnVzMJxp
jiQhVzXClfENKMd6HZ+Lf3Csld4A9i+85IcPrWCEtAsfz42oQ7JRQ9ZJpklRyp4=
=85jC
-END PGP SIGNATURE-

Re: Dragonflybsd's pf concurrent instead of single-threaded

[InterNetX - Robert Garrett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

There is 0 chance this works on OpenBSD. The underlying concepts that
not only make it possible on Dragonfly, but actually useful are not there.

As Henning Brauer pointed out, this makes no sense if the underlying
subsystems arent taken care of first. However it does seem to make a
difference on boxes with say 32 cores and a reasonable amount of memory.
Provided the underlying systems are taken care of.

the lwkt infrastructure mechanisms used here, are non trivial things,
and are really the essence of the reason for Dragonflys original fork to
begin with.

Lets see lwkt, lockmgr, critical sections, atomic adds, pretty much a
lesson in using dragonfly specific locking in this section of code.
not to mention this is a pretty old version of pf, and is in no way
current, with the pf in openbsd. Uprading pf with our set of changes
to support our locking mechanisms, is a seriously non trivial exercise.
trying to port this to a architecture without the underlying primitives
would be a massive task.

RG



On 07/08/2014 05:57 AM, Henning Brauer wrote:
> thanks for the laugh.
> 
> * Loïc Blot  [2014-07-07 10:21]:
>> It's a very interesting diff.
>>
>> If i have time i'll test it on -CURRENT on the two next weeks.
>>
>> -- 
>> Best regards, 
>>
>> Loïc BLOT, Engineering
>> UNIX Systems, Security and Network Engineer
>> http://www.unix-experience.fr
>>
>>
>> Le jeudi 03 juillet 2014 à 11:35 -0500, patric conant a écrit :
>>> This seems relevant to a lot of interest.
>>>
>>> commit 3a0038bfb239dd522057809c52d7d23dd2134c38
>>>
>>> Author: Matthew Dillon >> >
>>> Date:   Thu Jun 26 20:40:32 2014 -0700
>>>
>>> pf - make the bulk of PF concurrent under normal operation
>>>
>>> * state and ip fragment tables are now per-cpu.
>>>
>>> * packet paths acquire pf_token shared instead of exclusive.  Packet
>>>   processing runs concurrently.
>>>
>>> * Any dynamic rules updates will run synchronously for now.
>>>
>>> * State expiration from the pfpurge thread runs synchronously for now.
>>>   More work can be done here.
>>>
>>> * ioctl (and also pfsync) paths acquire pf_token exclusively.  That is,
>>>   primarily pfctl commands.  This includes rules updates and state 
>>> scans.
>>>   More work can be done here.
>>>
>>> Summary of changes:
>>>  sys/net/pf/Makefile|   2 +
>>>  sys/net/pf/if_pfsync.c |  85 +++---
>>>  sys/net/pf/if_pfsync.h |   2 +
>>>  sys/net/pf/pf.c| 260 --
>>>  sys/net/pf/pf_ioctl.c  | 427 
>>> +++--
>>>  sys/net/pf/pf_norm.c   | 118 --
>>>  sys/net/pf/pfvar.h |  17 +-
>>>  7 files changed, 588 insertions(+), 323 deletions(-)
>>> http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/3a0038bfb239dd522057809c52d7d23dd2134c38
>>
> 


Mit freundlichen Grüßen

Robert Garrett
Senior System Engineer
Technical Projects & Solutions
- --
InterNetX GmbH
Maximilianstr. 6
93047 Regensburg
Germany

Tel. +49 941 59559-480
Fax  +49 941 59559-245

www.internetx.com
www.facebook.com/InterNetX
www.twitter.com/InterNetX

Geschäftsführer/CEO: Thomas Mörz
Amtsgericht Regensburg, HRB 7142
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTu6ERAAoJEMrvovfl62c84hsH/0HDjGInnL5w8Ea6kaD2pVN+
jk2yJ2wY4iZFKVBbnb0Jn6ZLJK9DoUEtAOszwCIb69PbHNMmW3QkuVzpJj8lZcQy
BCGKuuImjHAR+MSsAASJl09sJc7s50Buo6HX2KeRAMKxkiBu6eBqenlhVYp6SFgZ
JsARhd+C4VJdzCJjzyFEunJEWAKs8dfawpQDeywhKgOeedxl0DnNSlS9Bdn6gpFe
3JuwtRb8Wy6cyt6ZilkNQWWnIa5b+8XMv7n1hNKqbMQRgY2qWjLbq50GuPikMN01
qAj+yrN88rWm980RZveRJJiZ/9UpDonHIvQZiveKdX4ZKXL1UMBjde0Igb8S9w4=
=Kpa9
-END PGP SIGNATURE-

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Henning Brauer]

thanks for the laugh.

* Loïc Blot  [2014-07-07 10:21]:
> It's a very interesting diff.
> 
> If i have time i'll test it on -CURRENT on the two next weeks.
> 
> -- 
> Best regards, 
> 
> Loïc BLOT, Engineering
> UNIX Systems, Security and Network Engineer
> http://www.unix-experience.fr
> 
> 
> Le jeudi 03 juillet 2014 à 11:35 -0500, patric conant a écrit :
> > This seems relevant to a lot of interest.
> > 
> > commit 3a0038bfb239dd522057809c52d7d23dd2134c38
> > 
> > Author: Matthew Dillon  > >
> > Date:   Thu Jun 26 20:40:32 2014 -0700
> > 
> > pf - make the bulk of PF concurrent under normal operation
> > 
> > * state and ip fragment tables are now per-cpu.
> > 
> > * packet paths acquire pf_token shared instead of exclusive.  Packet
> >   processing runs concurrently.
> > 
> > * Any dynamic rules updates will run synchronously for now.
> > 
> > * State expiration from the pfpurge thread runs synchronously for now.
> >   More work can be done here.
> > 
> > * ioctl (and also pfsync) paths acquire pf_token exclusively.  That is,
> >   primarily pfctl commands.  This includes rules updates and state 
> > scans.
> >   More work can be done here.
> > 
> > Summary of changes:
> >  sys/net/pf/Makefile|   2 +
> >  sys/net/pf/if_pfsync.c |  85 +++---
> >  sys/net/pf/if_pfsync.h |   2 +
> >  sys/net/pf/pf.c| 260 --
> >  sys/net/pf/pf_ioctl.c  | 427 
> > +++--
> >  sys/net/pf/pf_norm.c   | 118 --
> >  sys/net/pf/pfvar.h |  17 +-
> >  7 files changed, 588 insertions(+), 323 deletions(-)
> > http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/3a0038bfb239dd522057809c52d7d23dd2134c38
> 

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

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Henning Brauer]

* Franco Fichtner  [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? :)

ok, first thought: where's your diff? Not directed at Franco
specifically.

I don't owe anybody anything. OpenBSD hacking is supposed to be fun
for me.

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.

And the possible pf MP gains are drasticly overrated anyway.

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

Re: Dragonflybsd's pf concurrent instead of single-threaded

[James A. Peltier]

- Original Message -
| It's a very interesting diff.
| 
| If i have time i'll test it on -CURRENT on the two next weeks.
| 
| --
| Best regards,
| 
| Loïc BLOT, Engineering
| UNIX Systems, Security and Network Engineer
| http://www.unix-experience.fr

Considering that these patches use the DragonflyBSD specific lightweight 
tokens, it's *HIGHLY UNLIKELY* (100% guaranteed) not to work against any 
OpenBSD sources.

-- 
James A. Peltier
Manager, IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone   : 778-782-6573
Fax : 778-782-3045
E-Mail  : jpelt...@sfu.ca
Website : http://www.sfu.ca/itservices

To be original seek your inspiration from unexpected sources.

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Loïc Blot]

It's a very interesting diff.

If i have time i'll test it on -CURRENT on the two next weeks.

-- 
Best regards, 

Loïc BLOT, Engineering
UNIX Systems, Security and Network Engineer
http://www.unix-experience.fr


Le jeudi 03 juillet 2014 à 11:35 -0500, patric conant a écrit :
> This seems relevant to a lot of interest.
> 
> commit 3a0038bfb239dd522057809c52d7d23dd2134c38
> 
> Author: Matthew Dillon  >
> Date:   Thu Jun 26 20:40:32 2014 -0700
> 
> pf - make the bulk of PF concurrent under normal operation
> 
> * state and ip fragment tables are now per-cpu.
> 
> * packet paths acquire pf_token shared instead of exclusive.  Packet
>   processing runs concurrently.
> 
> * Any dynamic rules updates will run synchronously for now.
> 
> * State expiration from the pfpurge thread runs synchronously for now.
>   More work can be done here.
> 
> * ioctl (and also pfsync) paths acquire pf_token exclusively.  That is,
>   primarily pfctl commands.  This includes rules updates and state scans.
>   More work can be done here.
> 
> Summary of changes:
>  sys/net/pf/Makefile|   2 +
>  sys/net/pf/if_pfsync.c |  85 +++---
>  sys/net/pf/if_pfsync.h |   2 +
>  sys/net/pf/pf.c| 260 --
>  sys/net/pf/pf_ioctl.c  | 427 
> +++--
>  sys/net/pf/pf_norm.c   | 118 --
>  sys/net/pf/pfvar.h |  17 +-
>  7 files changed, 588 insertions(+), 323 deletions(-)
> http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/3a0038bfb239dd522057809c52d7d23dd2134c38

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Brad Smith]

On 05/07/14 8:01 PM, Predrag Punosevac wrote:

Franco Fichtner write:


I have immense respect for Matt as a user of his code since Amiga C
compiler. I probably speak for lots of people both in OpenBSD and
DragonFly camp if I say that I would prefer him to finish HAMMER2 and
leave concurrent threading in PF to Henning.



Talks about this date back at least two years.  These days NetBSD is
doing npf(4), and FreeBSD and DragonFly moved on to implement their
own SMP support.



The rumors are that npf is a vaporware.  DragonFly community is tiny. So
tiny that in-spite of HAMMER I could not use DragonFly on my production
file servers because it lacks LDAP support let alone NFSv4. FreeBSD
always had its own genuine firewall solution IPFW. IPFW is so good that
inspired even a better tool called iptables. Some people unfortunately
didn't buy it. OS X switched from IPFW to PF couple releases ago.


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



I would say it is about a time. PF has never meant to be portable. A
quick look on the version of PF in use in other BSDs is quite revealing.
That being said OpenBSD project has its own pace which has never being
dictated by "current fashion trends" or a noise made by people like me
who don't contribute the code. Thanks God for that!


What is the point of your posts other than filling peoples mail
boxes with useless bits?


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Predrag Punosevac]

Franco Fichtner write:

>> I have immense respect for Matt as a user of his code since Amiga C
>> compiler. I probably speak for lots of people both in OpenBSD and
>> DragonFly camp if I say that I would prefer him to finish HAMMER2 and
>> leave concurrent threading in PF to Henning.

> Talks about this date back at least two years.  These days NetBSD is
> doing npf(4), and FreeBSD and DragonFly moved on to implement their
> own SMP support.
>

The rumors are that npf is a vaporware.  DragonFly community is tiny. So
tiny that in-spite of HAMMER I could not use DragonFly on my production
file servers because it lacks LDAP support let alone NFSv4. FreeBSD
always had its own genuine firewall solution IPFW. IPFW is so good that
inspired even a better tool called iptables. Some people unfortunately
didn't buy it. OS X switched from IPFW to PF couple releases ago. 

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

I would say it is about a time. PF has never meant to be portable. A
quick look on the version of PF in use in other BSDs is quite revealing.
That being said OpenBSD project has its own pace which has never being
dictated by "current fashion trends" or a noise made by people like me
who don't contribute the code. Thanks God for that!

Predrag


>
> Cheers,
> Franco

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Franco Fichtner]

On 05 Jul 2014, at 23:42, Predrag Punosevac  wrote:

> I have immense respect for Matt as a user of his code since Amiga C
> compiler. I probably speak for lots of people both in OpenBSD and
> DragonFly camp if I say that I would prefer him to finish HAMMER2 and
> leave concurrent threading in PF to Henning.

Talks about this date back at least two years.  These days NetBSD is
doing npf(4), and FreeBSD and DragonFly moved on to implement their
own SMP support.

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


Cheers,
Franco

Re: Dragonflybsd's pf concurrent instead of single-threaded

[Predrag Punosevac]

patric conant wrote:


> This seems relevant to a lot of interest.

> commit 3a0038bfb239dd522057809c52d7d23dd2134c38

> Author: Matthew Dillon  >
> Date:   Thu Jun 26 20:40:32 2014 -0700
>
>  pf - make the bulk of PF concurrent under normal operation
>
>  * state and ip fragment tables are now per-cpu.
>
>  * packet paths acquire pf_token shared instead of exclusive.  Packet
>  processing runs concurrently.
>
>  * Any dynamic rules updates will run synchronously for now.
>
>  * State expiration from the pfpurge thread runs synchronously for now.
>  More work can be done here.
>
>   * ioctl (and also pfsync) paths acquire pf_token exclusively.  That
is,
>  primarily pfctl commands.  This includes rules updates and state
scans.
>  More work can be done here.
>
> Summary of changes:
>  sys/net/pf/Makefile|   2 +
>  sys/net/pf/if_pfsync.c |  85 +++---
>  sys/net/pf/if_pfsync.h |   2 +
>  sys/net/pf/pf.c| 260 --
>  sys/net/pf/pf_ioctl.c  | 427
> +++--
>  sys/net/pf/pf_norm.c   | 118 --
>  sys/net/pf/pfvar.h |  17 +-
>  7 files changed, 588 insertions(+), 323 deletions(-)
> http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/3a0038bfb239dd522057809c52d7d23dd2134c38


You are appear to be novice PF user and little bit naive about it.
Fortunately people in control of PF like Henning Brauer are not. 

For starters DragonFly uses 4 years old version of PF equivalent to
OpenBSD 4.8. PF is not very portable and you can follow my and Matt's
discussion on DragonFly users to see how painful for an OpenBSD user
like me is to use PF on DragonFly (I use Dragon Fly on one of my
production servers).

http://lists.dragonflybsd.org/pipermail/users/2014-June/128664.html

What that public exchange doesn't reveal is how many things in PF in
particular in PF IPv6 support IIRC got broken so that Matt got above to
work. FreeBSD has done something similar earlier and they have their own
PF changes also applied against an ancient version of PF.

I have immense respect for Matt as a user of his code since Amiga C
compiler. I probably speak for lots of people both in OpenBSD and
DragonFly camp if I say that I would prefer him to finish HAMMER2 and
leave concurrent threading in PF to Henning.

Predrag