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, still you post a patch that needs our review and time ? This is crazy. I am tempted to stop here. Oh well... 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. percpu_alloc() is not meant to be used thousand of times per second. It is not scalable. You consume 16 bytes per counter in the main table, while 4 bytes index should be enough on SMP build. Most firewalls I know use two or four cpus at most. They care about speed, not really because iptables duplicates table on each cpu. By the way, not using NUMA can definitly hurt firewalls with many rules, unless you make sure the main table is vmalloced() with node distribution, not a single node. Even with this, this can hurt latencies. 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 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
