On 2025-02-17 17:20:53 [+0100], Florian Westphal wrote: > > > I think we might get away with losing counters on the update > > > side, i.e. rcu_update_pointer() so new CPUs won't find the old > > > binary blob, copy the counters, then defer destruction via rcu_work > > > or similar and accept that the counters might have marginally > > > changed after the copy to userland and before last cpu left its > > > rcu critical section. > > > > I could do that if we want to accelerate it. That is if we don't have > > the muscle to point people to iptables-nft or iptables-legacy-restore. > > > > Speaking of: Are there plans to remove the legacy interface? This could > > be used as meet the users ;) But seriously, the nft part is around for > > quite some time and there is not downside to it. > > Yes, since 6c959fd5e17387201dba3619b2e6af213939a0a7 > the legacy symbol is user visible so next step is to replace > various "select ...TABLES_LEGACY" with "depends on" clauses. Okay. So I would repost the series fixing what the bot complained in 2/3. The action in case people complain about slow insertion would be: - Use iptables-legacy-restore if mass insertion is performance critical. - Use iptables-nft which does not have this problem. - If both option don't work, copy the counters immediately risking to miss in-flight updates, free the memory after a grace period. Any objections? Sebastian
