[v4,nf-next,0/2] netfilter: x_tables: speed up iptables-restore

iptables-restore can take quite a long time when sytem is busy, in order
of half a minute or more.

The main reason for this is the way ip(6)tables performs table swap:

When xt_replace_table assigns the new ruleset pointer, it does
not wait for other processors to finish with old ruleset.

Instead it relies on the counter sequence lock in get_counters().

This works but this is costly if system is busy as each counter read
operation can possibly be restarted indefinitely.

Instead, make xt_replace_table wait until all processors are known to not
use the old ruleset anymore.

This allows to read the old counters without any locking, no cpu is
using the ruleset anymore so counters can't change either.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, Oct 12, 2017 at 01:13:49AM +0200, Florian Westphal wrote:
> iptables-restore can take quite a long time when sytem is busy, in order
> of half a minute or more.
> 
> The main reason for this is the way ip(6)tables performs table swap:
> 
> When xt_replace_table assigns the new ruleset pointer, it does
> not wait for other processors to finish with old ruleset.
> 
> Instead it relies on the counter sequence lock in get_counters().
> 
> This works but this is costly if system is busy as each counter read
> operation can possibly be restarted indefinitely.
> 
> Instead, make xt_replace_table wait until all processors are known to not
> use the old ruleset anymore.
> 
> This allows to read the old counters without any locking, no cpu is
> using the ruleset anymore so counters can't change either.

Series applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html