netdev - Re: [PATCH RFC net-next 4/4] bridge: add ability to turn off fdb used updates

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] [day] [month] [year] [list]

Message-ID: <dbd755ac-bdb3-cc1e-0764-8fe460d0d4be@cumulusnetworks.com>
Date:   Sat, 4 Feb 2017 17:45:14 +0100
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, roopa@...ulusnetworks.com,
        stephen@...workplumber.org
Subject: Re: [PATCH RFC net-next 4/4] bridge: add ability to turn off fdb used
 updates

On 03/02/17 03:47, David Miller wrote:
> From: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
> Date: Tue, 31 Jan 2017 16:31:58 +0100
> 
>> @@ -197,7 +197,8 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
>>  		if (dst->is_local)
>>  			return br_pass_frame_up(skb);
>>  
>> -		dst->used = jiffies;
>> +		if (br->used_enabled)
>> +			dst->used = jiffies;
> 
> Have you tried:
> 
> 	if (dst->used != jiffies)
> 		dst->used = jiffies;
> 
> If that isn't effective, you can tweak the test to decrease the
> granularity of the value.  Basically, if dst->used is within
> 1 HZ of jiffies, don't do the write.
> 
> I suspect this might help a lot, and not require a new bridging
> option.
> 

After running a ton of tests with different granularity settings and improvements
similar to:

br->jiffy_update_mask = rounddown_pow_of_two(clock_t_to_jiffies(1)) - 1

fast_path:
if (!(jiffies & br->jiffy_update_mask) && dst->used != jiffies)
	dst->used = jiffies;

in order to bring down the updates even lower, it seems that just going with the
comparison is enough - I can't see any measurable win by bringing it even lower (e.g.
HZ / USER_HZ granularity).

So I'm going with the simpler approach and just doing the comparison.

Thanks,
 Nik