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. 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.
