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:	Fri, 19 Nov 2010 12:15:06 +0100 (CET)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	Eric Dumazet <eric.dumazet@...il.com>
cc:	Changli Gao <xiaosuo@...il.com>, Patrick McHardy <kaber@...sh.net>,
	"David S. Miller" <davem@...emloft.net>,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [RFC PATCH] netfilter: remove the duplicate tables

On Thursday 2010-11-18 16:43, Eric Dumazet wrote:

>Le jeudi 18 novembre 2010 à 22:39 +0800, Changli Gao a écrit :
>> As only xt_counters are private to each CPU, we don't need to maintain
>> a whole individual table for each CPU.
>> 
>> In the kernel space, we use the memory of ipt_entry.counters to save a
>> pointer to a percpu xt_counters. When iptables runs, it only update the
>> counters on its own CPU.
>> 
>> On non SMP platforms, no change is made.
>> 
>> Only the code of iptables is converted. Thanks for reviews.
>> 
>
>Changli
>
>I answered you a (difficult) work was in progress

Was it? Quoting Patrick from 24h prior to this post:

|so patches to get rid of the table duplication are highly welcome.

>still you post a patch that needs our review and time ? This is crazy.

You do not need to do it, but I will happily look at this.
Of course my observations are the same as yours:

>Your way of allocating a percpu counter for each counter is a pure TLB
>and cache line blower (up to two cache lines per counter), not counting
>the time needed to load a new table with 10.000 entries. Some people
>still use scripts with hundred of calls to iptables.

The two are statistically independent though. Even for a loaded 
ruleset, the TLB/DC miss accumulation will be desastrous - as I've found 
with linked-list rules/small allocs.

>Allocating one contiguous percpu var for all counters is a must.
>
>Problem is : percpu alloc doesnt allow big allocations.
>
>#define PCPU_MIN_UNIT_SIZE      PFN_ALIGN(32 << 10)
>
>So max allocation is 32 Kbytes, thats 2048 'xt_counters' only.
>-> cannot really use pcpu-alloc, but a kmalloc_node() or vmalloc_node()
>per cpu

.. as is already done for jumpstack ;-)
--
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