parallelizing ipfw table

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

  • Next message: Gleb Smirnoff: "Re: parallelizing ipfw table" 
    Date: Sun, 27 Nov 2005 03:59:43 +0300
To: ru@FreeBSD.org, Vsevolod Lobko <seva@ip.net.ua>, rwatson@FreeBSD.org

      Colleagues,

      in ipfw(4) we've got a reader/writer locking semantics. The ipfw
    lookups performed on packet forwarding obtain reader lock on ipfw
    chain, while altering the chain requires writer access on chain.

    So, in multiprocessor multiinterface box we achieve a parallizm
    almost without any contention.

    However, ipfw tables lock the RADIX trie on every lookup. At the
    first glance the radix.c:rn_lookup() function is reenterable. This
    means that we can do two parallel RADIX lookups. So, I suggest
    to eliminate the RADIX trie locking in ipfw, and utilize the
    locking that is already present in ipfw. This will:

      - reduce number of mutex operations for each packer
      - remove contention from parallel ipfw_chk() lookups

    A patch displaying the idea is attached. Not tested yet, read
    below. The patch moves the tables array into the ip_fw_chain
    structure. This is not necessary now, but in future we can
    have multiple independent chains in ipfw, that's why I try
    to avoid usage of &layer3_chain in the functions that are
    deeper in the call graph. I try to supply chain pointer
    from the caller.

    The only problem is the caching in table lookup. This "hack"
    makes the lookup function modify the table structure. We need
    to remove caching to make the lookup_table() function fully
    lockless and reenterable at the same time. The attached patch
    doesn't removes caching, since it only displays the original
    idea. 

    -- 
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: Gleb Smirnoff: "Re: parallelizing ipfw table"

    Relevant Pages

    • Re: parallelizing ipfw table
      ... T> in ipfwwe've got a reader/writer locking semantics. ... T> lookups performed on packet forwarding obtain reader lock on ipfw ... T> chain, while altering the chain requires writer access on chain. ... T> means that we can do two parallel RADIX lookups. ...
      (freebsd-net)
    • Re: per-interface packet filters
      ... A>> A>> (Now I speak only about ipfw. ... Supply chain identifier in void arg. ... A>> interface and ipfw on other. ... If some developer likes idea of per-interface filters and prefers smth ...
      (freebsd-net)
    • Re: per-interface packet filters
      ... A>> (Now I speak only about ipfw. ... Supply chain identifier in void arg. ... You can register only once with pfil. ... the pfil API is designed to attach a list of generic filters to ...
      (freebsd-net)
    • Re: FW: monitor ALL connections to ALL ports
      ... >> ipfw add count log all from any to any ... > chain is parsed on a first-match basis, ... There's another problem I can see here: this setup will generate a log ... ${fwcmd} add pass log tcp from any to $80 setup ...
      (FreeBSD-Security)