[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1341595171.2923.2.camel@bwh-desktop.uk.solarflarecom.com>
Date: Fri, 6 Jul 2012 18:19:31 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: David Miller <davem@...emloft.net>
CC: <netdev@...r.kernel.org>
Subject: Re: [PATCH] ipv4: Avoid overhead when no custom FIB rules are
installed.
On Thu, 2012-07-05 at 22:31 -0700, David Miller wrote:
> If the user hasn't actually installed any custom rules, or fiddled
> with the default ones, don't go through the whole FIB rules layer.
>
> It's just pure overhead.
>
> Instead do what we do with CONFIG_IP_MULTIPLE_TABLES disabled, check
> the individual tables by hand, one by one.
>
> Also, move fib_num_tclassid_users into the ipv4 network namespace.
[...]
> --- a/net/ipv4/fib_rules.c
> +++ b/net/ipv4/fib_rules.c
[...]
> @@ -189,12 +190,14 @@ errout:
>
> static void fib4_rule_delete(struct fib_rule *rule)
> {
> + struct net *net = rule->fr_net;
> #ifdef CONFIG_IP_ROUTE_CLASSID
> struct fib4_rule *rule4 = (struct fib4_rule *) rule;
>
> if (rule4->tclassid)
> - fib_num_tclassid_users--;
> + net->ipv4.fib_num_tclassid_users--;
> #endif
> + net->ipv4.fib_has_custom_rules = true;
> }
[...]
Do you really mean to set fib_has_custom_rules = true on deletion?
Shouldn't it conditionally be set false? (Though the condition may be
too expensive to evaluate here without maintaining a separate counter.)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists