Re: parallelizing ipfw table

From: Gleb Smirnoff (glebius_at_FreeBSD.org)
Date: 11/28/05

  • Next message: FreeBSD bugmaster: "Current problem reports assigned to you"
    Date: Mon, 28 Nov 2005 13:52:50 +0300
    To: "."@babolo.ru
    
    

    On Mon, Nov 28, 2005 at 01:42:41PM +0300, .@babolo.ru wrote:
    .> > On Mon, Nov 28, 2005 at 08:27:32AM +0200, Ruslan Ermilov wrote:
    .> > R> > Can you try my patch? Since it reduces the total number of mutex
    .> > R> > operations it should be a win on UP, too.
    .> > R> We're currently based on 4.x. You can try it yourself: create
    .> > R> a table with 10000 entries and with value 13. Then write a
    .> > R> ruleset with 13 rules that look up this table so that the last
    .> > R> rule looks it up with value 13, and do a benchmark. Let me
    .> > R> know what are results with and without caching.
    .> > Such kind of firewall looks like unoptimized. Why should we optimize the
    .> > code for non-optimized setups. Can't we avoid looking into one table
    .> > 13 times each packet?
    .>
    .> add 47400 pipe 47400 ip from table(0, 0) to any
    .> add 47401 pipe 47401 ip from table(0, 1) to any
    .> add 47402 pipe 47402 ip from table(0, 2) to any
    .> add 47403 pipe 47403 ip from table(0, 3) to any
    .> add 47404 pipe 47404 ip from table(0, 4) to any
    .> add 47405 pipe 47405 ip from table(0, 5) to any
    .> add 47406 pipe 47406 ip from table(0, 6) to any
    .> add 47407 pipe 47407 ip from table(0, 7) to any
    .> add 47408 pipe 47408 ip from table(0, 8) to any
    .> add 47409 pipe 47409 ip from table(0, 9) to any
    .>
    .> for different traffic consumers listed in table(0)

    I understand now. Ruslan has sent me a sample setup, too. Anyway, the
    current optimization is broken on SMP, because it stores the cache
    in the table itself. Parallel processing of the different packets on
    SMP breaks the optimization, since different instances of ipfw_chk()
    trash the cached addr one after another.

    I have two ideas about this. First, store the cache on stack. Second,
    utilize the table entry value in the rule. In this case your block
    can be converted to:

      add N pipe \$val ip from table(0) to any

    \$val means the value of the entry in the table.

    -- 
    Totus tuus, Glebius.
    GLEBIUS-RIPN GLEB-RIPE
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
    

  • Next message: FreeBSD bugmaster: "Current problem reports assigned to you"

    Relevant Pages

    • On-disk indexing for "Project Ideas" page
      ... The kernel usually does the lookup by starting at the beginning ... of the directory and going through, comparing each entry in turn. ... name cache described in Section 6.6. ...
      (freebsd-current)
    • [BUGFIX]{PATCH] flush icache on ia64 take2
      ... This is a patch for fixing icache flush race in ia64by implementing ... This patch guarantees cache is flushed before set_ptecall. ... Update PTEP with ENTRY, which is guaranteed to be a less ... Clear the pte entry and flush it first, ...
      (Linux-Kernel)
    • [BUGFIX][PATCH] DO flush icache before set_pte() on ia64.
      ... Montecito, new ia64 processor, has separated L2 i-cache and d-cache, ... L1 cache is also separated but L1 D-cache is write-through. ... Update PTEP with ENTRY, which is guaranteed to be a less ... Clear the pte entry and flush it first, ...
      (Linux-Kernel)
    • Re: Help - Outlook names cache
      ... > popping up in the “to” field when he types in “abc” for example. ... > can’t delete a single cached entry. ... The autocompletion cache has no connection with the Contacts folder at all. ... Outlook, by itself, can't accomplish your goal. ...
      (microsoft.public.outlook.general)
    • Re: Help - Outlook names cache
      ... >> can’t delete a single cached entry. ... > The autocompletion cache has no connection with the Contacts folder at all. ... > Outlook, by itself, can't accomplish your goal. ...
      (microsoft.public.outlook.general)