Stephen Hemminger a écrit :
> This version of x_tables (ip/ip6/arp) locking uses a per-cpu
> recursive lock that can be nested.
>
> The idea for this came from an earlier version done by Eric Dumazet.
> Locking is done per-cpu, the fast path locks on the current cpu
> and updates counters. This reduces the contention of a
> single reader lock (in 2.6.29) without the delay of synchronize_net()
> (in 2.6.30-rc2).
>
> The mutex that was added for 2.6.30 in xt_table is unnecessary since
> there already is a mutex for xt[af].mutex that is held.
>
> Signed-off-by: Stephen Hemminger <shemminger@xxxxxxxxxx
Signed-off-by: Eric Dumazet <dada1@xxxxxxxxxxxxx>
Tested today on various machines and no problem so far
tbench/oprofile results, 3.7236% cpu spent in ipt_do_table, and 0.84% used
on read_lock/read_unlock
c04a5c30 <ipt_do_table>: /* ipt_do_table total: 217134 3.7236 */
...
349 0.0060 :c04a5ccc: call c04ce380 <_read_lock>
23914 0.4101 :c04a5cd1: mov 0xc(%edi),%eax
...
:c04a5ecb: call c04ce5f0 <_read_unlock_bh>
25279 0.4335 :c04a5ed0: cmpb $0x0,-0xd(%ebp)
"iptables -L" fetches its data very fast too.
150 us on a 8 cpus machine, small firewall rules.
400-700 us on same machine, 1000 fw rules set (160000 bytes per cpu)
depending on network trafic (from light to flood)
Thanks
>
> ---
> CHANGES
> - reader and write now inline
> - only acquire one cpu write lock at a time
> - write lock pushed down into get_counters
>
> include/linux/netfilter/x_tables.h | 50 +++++++++++++--
> net/ipv4/netfilter/arp_tables.c | 121 ++++++++++---------------------------
> net/ipv4/netfilter/ip_tables.c | 120 +++++++++---------------------------
> net/ipv6/netfilter/ip6_tables.c | 120 ++++++++++--------------------------
> net/netfilter/x_tables.c | 55 +++++++++-------
> 5 files changed, 174 insertions(+), 292 deletions(-)
>
--
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
