Phil Sutter <phil@xxxxxx> wrote: > So IIUC, JSON parser will now collapse all new ruleset items into a tree > and use the existing nft_cmd_expand() to split things up again. This may > impose significant overhead depending on input data (bogus/OpenShift use > cases involving many chains maybe) on one hand, on the other might allow > for overhead elimination in other cases (e.g. long lists of 'add > element' commands for different sets in alternating fashion). > > We may want to do this for standard syntax as well if the benefits > outweigh the downsides. Thus generalize the JSON-specific helpers you > wrote for use within bison parser, too? It tries to do same as bison parser when using nft -f with a standard 'list ruleset' input. A 'batch file' with sequential 'add table x', 'add chain x c' etc. does separate 'add' requests. The json parser is supposed to follow this, i.e. 'ctx->in_ruleset' is only supoosed to be set when this is a json listing, not when some input daemon is feeding independent add requests. > An alternative might be to reorder code in table_print_json_full(), > copying what nft_cmd_expand() does for CMD_OBJ_TABLE. AIUI, it should > solve the current issue of failing 'nft -j list ruleset | nft -j -f -' > for special cases. Its indeed possible to reorder things but I was not sure if there is a simple way to do this. One case is 'verdict map', where the elements need to be created after the chains. The other one is rules, those need to come after the chains. So what could work is: 1. tables 2. chains (but not rules) 3. flowtables 4. objects 5. maps and sets 6. map/set elements 7. rules (they could reference maps and sets or objects) If you prefer to resolve it by sorting the output (input) as needed please let me know.
