Re: [iptables-nftables RFC v3 PATCH 11/16] nft: Refactor firewall printing so it reuses already parsed cs struct

[Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>]

Hi Pablo,

>> Could you recheck in detail patches 3/16 and 4/16?
>> If there is no flaws in the translation engine, we might just go for
>> it at it is.
> I'm not convinced that this approach is the way to go. In the payload
> case, the number of instruction tuples will explode, and you will have
> to iterate many times to find the corresponding parser.

There are many ways to reduce drastically such lookup process, current 
implementation is just here to prove it works.
I have actually some code for that, by extending the instruction 
declaration with extra infos, it kills looping. Not finished though.
(have also a solution for not pre-loading all extensions, btw)

Actually NAT is probably the worst example. I should have implemented 2 
or 3 totally different other extensions.
Because nat exists as its own expression in nftables, so indeed it's 
really easy to pick it up in an expression list.
if (expr == "nat") parse_nat();

But it's not going to be that simple with complex set of different 
expressions representing one extension.
Of course it's can still work with programmatic way but it's going to be 
really annoying in maintenance, entangled code, bug prone etc...
Since every time you will support a new extension, code will need to change.
With my approach: no code change needed anymore, just declaring the 
right instruction which is very trivial.

> Anyway, I really think we have to start by converting nft to ipt
> command state in one single patch, as your patches 11-13 do, we need
> it for whatever approach we decide to follow. If you don't have time
> to make that rebase, I'll try to find some spare time to work on it.
> Let me know.

I can find time.

Tomasz