On Thu, Oct 17, 2019 at 07:06:28PM +0200, Phil Sutter wrote: > On Thu, Oct 17, 2019 at 12:08:16PM +0200, Pablo Neira Ayuso wrote: > > 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. > > Yes, let's please give it a try. Fingers crossed, but if it blows up > I'll either fix it or revert it myself. :) Thanks Phil, let's do that!
