Re: parallelizing ipfw table

From: Ruslan Ermilov (ru_at_freebsd.org)
Date: 11/28/05

  • Next message: Gleb Smirnoff: "Re: parallelizing ipfw table" 
    Date: Mon, 28 Nov 2005 08:27:32 +0200
To: Gleb Smirnoff <glebius@freebsd.org>

    On Sun, Nov 27, 2005 at 10:59:14PM +0300, Gleb Smirnoff wrote:
    > Ruslan,
    >
    > On Sun, Nov 27, 2005 at 09:45:45PM +0200, Ruslan Ermilov wrote:
    > R> Nope, I need this caching. It's for looking up the same table
    > R> several times in a row but with various values. For example,
    > R> we use ipfw tables to route the traffic to the correct dummynet
    > R> pipe, where value is the bandwidth, and this caching helps a lot.
    >
    > Have you benchmarked that this caching is important? On a router
    > that serves a lot of parallel traffic flows the caching is not
    > a benefit, but additional processing. I think we should optimize
    > the code for more loaded environments, since we don't care about
    > CPU consumption in a less loaded setup - whether it is 0.1% or 0.11%.
    >
    I'm talking about the following case: the same packet is
    processed by a firewall ruleset that has N rules that
    look up the same ipfw table but with different "values",
    to select a correct dummynet pipe.

    > In general such kind of caching in network code is an old fashion,
    > that causes a problems when we attempt to make code more
    > parallelizable. We alreade removed rtcache in ip_output.c rev. 1.201
    > and we will soon remove route caching in gif(4), because it causes
    > problems on SMP.
    >
    > Can you try my patch? Since it reduces the total number of mutex
    > operations it should be a win on UP, too.
    >
    We're currently based on 4.x. You can try it yourself: create
    a table with 10000 entries and with value 13. Then write a
    ruleset with 13 rules that look up this table so that the last
    rule looks it up with value 13, and do a benchmark. Let me
    know what are results with and without caching.

    Cheers, 

    -- 
Ruslan Ermilov
ru@FreeBSD.org
FreeBSD committer
_______________________________________________
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
      ... R>> R> pipe, where value is the bandwidth, and this caching helps a lot. ... R> I'm talking about the following case: the same packet is ... R> processed by a firewall ruleset that has N rules that ... Can you please show me how this ruleset looks like? ...
      (freebsd-net)
    • Re: parallelizing ipfw table
      ... R> pipe, where value is the bandwidth, and this caching helps a lot. ... that serves a lot of parallel traffic flows the caching is not ... the code for more loaded environments, ... and we will soon remove route caching in gif, ...
      (freebsd-net)