On Thu, 19 Feb 2009 15:56:18 -0800
Rick Jones [off-list ref] wrote:

Eric Dumazet wrote:

quoted

Stephen Hemminger a écrit :

quoted

The reader/writer lock in ip_tables is acquired in the critical path of
processing packets and is one of the reasons just loading iptables can cause
a 20% performance loss. The rwlock serves two functions:

1) it prevents changes to table state (xt_replace) while table is in use.
  This is now handled by doing rcu on the xt_table. When table is
  replaced, the new table(s) are put in and the old one table(s) are freed
  after RCU period.

2) it provides synchronization when accesing the counter values.
  This is now handled by swapping in new table_info entries for each cpu
  then summing the old values, and putting the result back onto one
  cpu.  On a busy system it may cause sampling to occur at different
  times on each cpu, but no packet/byte counts are lost in the process.

Signed-off-by: Stephen Hemminger <redacted>

Acked-by: Eric Dumazet <redacted>

Sucessfully tested on my dual quad core machine too, but iptables only (no
ipv6 here)

BTW, my new "tbench 8" result is 2450 MB/s, (it was 2150 MB/s not so long ago)

Thanks Stephen, thats very cool stuff, yet another rwlock out of kernel :)

Do you folks need/want further testing against the 32-core setup?

It would be good to combine all 3 (iptables-rcu, timer change, and conntrack lock)
to see what the overhead change is.