lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 15 Jul 2009 09:43:11 +0200
From:	Robert Olsson <robert@...ur.slu.se>
To:	Jarek Poplawski <jarkao2@...il.com>
Cc:	David Miller <davem@...emloft.net>,
	Paweł Staszewski <pstaszewski@...are.pl>,
	Linux Network Development list <netdev@...r.kernel.org>,
	Robert Olsson <Robert.Olsson@...a.slu.se>,
	"Jorge Boncompte [DTI2]" <jorge@...2.net>
Subject: [PATCH net-next] Re: rib_trie / Fix inflate_threshold_root. Now=15
	size=11 bits


Jarek Poplawski writes:


Looks good. Maybe we're getting close to some generic solution to take 
a very optimistic approach wrt thresholds for root node and adjust to 
settings without the warning. Or maybe now even remove warning totally
with stata counter?

Can we even consider some other different strategy for bumping up the root 
node. 

We need all lookup performance we can get when we now try to route without 
the route cache. And we probably need to evaluate the cost for the multiple 
lookups again at least for LOCAL and MAIN when we talking routing well at 
least straight-forward simple routing. (Semantic change)

I think I've got ~6.2 Gbit/s for simplex forwarding using traffic patterns 
we see in/close to Internet core. This w/o route cache on our hi-end opterons
with 8 CPU cores using niu and ixgbe. I'll test again and your patches when
I'm back from vacation.

Cheers
					--ro

 > So it looks like the patch tested earlier could be still useful; after
 > changing the inflate_threshold_root it seems these warnings should be
 > very rare but there is no reason to alarm users with something they
 > can't fix optimally, anyway.
 > 
 > Thanks,
 > Jarek P.
 > --------------------->
 > ipv4: Fix inflate_threshold_root automatically
 > 
 > During large updates there could be triggered warnings like: "Fix
 > inflate_threshold_root. Now=25 size=11 bits" if inflate() of the root
 > node isn't finished in 10 loops. It should be much rarer now, after
 > changing the threshold from 15 to 25, and a temporary problem, so
 > this patch tries to handle it automatically using a fix variable to
 > increase by one inflate threshold for next root resizes (up to the 35
 > limit, max fix = 10). The fix variable is decreased when root's
 > inflate() finishes below 7 loops (even if some other, smaller table/
 > trie is updated -- for simplicity the fix variable is global for now).
 > 
 > Reported-by: Pawel Staszewski <pstaszewski@...are.pl>
 > Reported-by: Jorge Boncompte [DTI2] <jorge@...2.net>
 > Tested-by: Pawel Staszewski <pstaszewski@...are.pl>
 > Signed-off-by: Jarek Poplawski <jarkao2@...il.com>
 > ---
 > 
 > diff -Nurp a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
 > --- a/net/ipv4/fib_trie.c	2009-07-13 13:32:53.000000000 +0200
 > +++ b/net/ipv4/fib_trie.c	2009-07-13 15:16:18.000000000 +0200
 > @@ -327,6 +327,8 @@ static const int inflate_threshold = 50;
 >  static const int halve_threshold_root = 15;
 >  static const int inflate_threshold_root = 25;
 >  
 > +static int inflate_threshold_root_fix;
 > +#define INFLATE_FIX_MAX 10	/* a comment in resize() */
 >  
 >  static void __alias_free_mem(struct rcu_head *head)
 >  {
 > @@ -617,7 +619,8 @@ static struct node *resize(struct trie *
 >  	/* Keep root node larger  */
 >  
 >  	if (!tn->parent)
 > -		inflate_threshold_use = inflate_threshold_root;
 > +		inflate_threshold_use = inflate_threshold_root +
 > +					inflate_threshold_root_fix;
 >  	else
 >  		inflate_threshold_use = inflate_threshold;
 >  
 > @@ -641,15 +644,27 @@ static struct node *resize(struct trie *
 >  	}
 >  
 >  	if (max_resize < 0) {
 > -		if (!tn->parent)
 > -			pr_warning("Fix inflate_threshold_root."
 > -				   " Now=%d size=%d bits\n",
 > -				   inflate_threshold_root, tn->bits);
 > -		else
 > +		if (!tn->parent) {
 > +			/*
 > +			 * It was observed that during large updates even
 > +			 * inflate_threshold_root = 35 might be needed to avoid
 > +			 * this warning; but it should be temporary, so let's
 > +			 * try to handle this automatically.
 > +			 */
 > +			if (inflate_threshold_root_fix < INFLATE_FIX_MAX)
 > +				inflate_threshold_root_fix++;
 > +			else
 > +				pr_warning("Fix inflate_threshold_root."
 > +					   " Now=%d size=%d bits fix=%d\n",
 > +					   inflate_threshold_root, tn->bits,
 > +					   inflate_threshold_root_fix);
 > +		} else {
 >  			pr_warning("Fix inflate_threshold."
 >  				   " Now=%d size=%d bits\n",
 >  				   inflate_threshold, tn->bits);
 > -	}
 > +		}
 > +	} else if (max_resize > 3 && !tn->parent && inflate_threshold_root_fix)
 > +		inflate_threshold_root_fix--;
 >  
 >  	check_tnode(tn);
 >  
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ