[CFT] SMP-friendly pf

[Gleb Smirnoff]

  Ermal,

On Fri, Jun 08, 2012 at 12:39:43PM +0200, Ermal Lu?i wrote:
E> On Fri, Jun 8, 2012 at 8:17 AM, Gleb Smirnoff <glebius at freebsd.org> wrote:
E> As i already asked in private wihtout a documentation/schema
E> describing how you protect the various elements in pf(4) this is very
E> hard to review.

As I already replied, one should read commit logs as well as some details
there are in the email you were replying to.

E> - What do you do to allow correctness on statistics?

Nothing. Statistics are not precise in the SMP-friendly pf. This is
an issue for all counters in our networking stack - counters on ifnets,
in ipfw, many others. Using atomic operations to keep them precise
is too expensive.

We need some solution to make cheap and precise counters. I think this
should pcpu data. I already did made some tests proving the effectiveness
of this approach. However, to get this to a commitable state I need
help from some seniour kernel developers. Anyway cheap+precise counters
should be discussed in separate thread.

E> - What do you with tables protection, are they under same lock as rules...?

Yes, and this was mentioned in the mail you are replying to. 

E> - How is if-bound versus floating states maintained?

Nothing changed for them. Should there be something tricky?

E> - What is protecting scrub ruleset?
E> - What is protecting nat ruleset?

Same lock as rules. I suppose that is quite clear from my mail.

E> - How you solved synproxy ? Is it scalable?

You know how I solved it, you even commented on that commit:

http://lists.freebsd.org/pipermail/svn-src-projects/2012-April/005056.html

Can you please explain your concerns on scalability of the approach taken?

E> - Do you think you have introduced possiblity of security issues with
E> taskqueues you introduce?

Can you please explain what security issues do you see in taskqueue?

E> There are many how? in this implementation that are difficult to see
E> without you telling!

I am open to questions.

-- 
Totus tuus, Glebius.