On Thu, Oct 17, 2019 at 11:03:32AM +0200, Pablo Neira Ayuso wrote: > On Tue, Oct 15, 2019 at 01:41:44PM +0200, Phil Sutter wrote: > > Fourth try at caching optimizations implementation. > > > > Changes since v3: > > > > * Rebase onto current master after pushing the accepted initial three > > patches. > > * Avoid cache inconsistency in __nft_build_cache() if kernel ruleset > > changed since last call. > > I still hesitate with this cache approach. > > Can this deal with this scenario? Say you have a ruleset composed on N > rules. > > * Rule 1..M starts using generation X for the evaluation, they pass > OK. > > * Generation is bumped. > > * Rule M..N is evaluated with a diferent cache. > > So the ruleset evaluation is inconsistent itself since it is based on > different caches for each rule in the batch. It might be that rule M fails because a user-defined chain is not found anymore, error reporting will not be consistent on races, and who knows what else. Anyway, if you want to go for this approach, merge it upstream and let's test how it goes... this batch looks much better indeed than v1, so push it out. Acked-by: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
