On Wed, May 18, 2022 at 02:38:14PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > This all seems fragile to me, with huge potential to add subtle bugs > > > that will be hard to track down. > > > > We can expose flags to indicate that an expression is reduced and > > expressions that are prefetched. > > > > New test infrastructure will help to catch bugs, more selftests and > > userspace validation of bytecode through exposed flags. > > > > It would be good not to re-fetch data into register that is already > > there. > > I wonder if we should explore doing this from userspace only, i.e. > provide hints to kernel which expressions should be dropped in a given > chain. > > Thats more transparent and would permit to reshuffle expressions, > e.g. first add all 'load instructions' and then do the comparisions > register opererations. > > Kind of reverse approach to what you and Phil are doing, instead of > eliding expressions in the data path representation based on in-kernel > logic and a debug infra that annotates 'soft off' expressions, annotate > them in userspace and then tell kernel what it can discard. > > Downside is that userspace would have to delete+re-add entire chain to > keep the 'elide' as-is. Problem is incremental ruleset updates, we'd go back to iptables way (dump ruleset, rework, reload). > With proposed scheme, we will have to patch kernel and then tell users > that they must upgrade kernel or risk that their ruelset is incorrect. > > With userspace approach, we could slowly extend nft and add explicit > optimization flags to the commandline tool, with default of re-fetch. I would revisit to enable expression reduction for keys that do not depend on datapath data by canceling tracking in such case.
