Date: Fri, 8 Jun 2012 23:18:49 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Ermal Lu?i <eri@FreeBSD.org> Cc: pf@FreeBSD.org Subject: Re: [CFT] SMP-friendly pf Message-ID: <20120608191849.GD28613@FreeBSD.org> In-Reply-To: <CAPBZQG363E7jNoQUCBOZr7A%2BgbUrBdFuCfaymd-c7Dh%2Bs7r%2B0Q@mail.gmail.com> References: <20120608061737.GA28197@glebius.int.ru> <CAPBZQG363E7jNoQUCBOZr7A%2BgbUrBdFuCfaymd-c7Dh%2Bs7r%2B0Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120608191849.GD28613>