Kerin Millar <kfm@xxxxxxxxxxxxx> wrote:
> On Wed, 10 Jul 2024, at 7:34 PM, William N. wrote:
> > On Tue, 2 Jul 2024 19:03:18 -0000 William N. wrote:
> >
> >> [...]
> >> Also, it is not clear what is the actual "load" of different
> >> instructions in terms of CPU cycles and memory, i.e. one instruction
> >> may look as "one" but may actually cost more than another 2, right?
>
> Indeed. It cannot be presumed that all instructions are equal in expense.
Yes, but then again nft will try to make reasonable choices.
tcp dport { 22, 80 } will not allocate a huge hash table for two values.
Is it faster than
tcp dport 22
tcp dport 80
?
No idea. And given the volume of bugs I don't really care too much.
> >> What is the proper way to evaluate and optimize rule efficiency?
> >
> > Are those difficult or somehow inappropriate questions?
> > Or is there a better place to ask?
>
> You are enquiring as to how to assess the relative efficiency of the bytecode instructions through the direct understanding of how they are processed by the nftables VM. Said VM is unique and - as far as I know - wholly undocumented. As regards difficulty, the intersection of people who follow the list and possess the necessary expertise can probably be conveyed quite comfortably by a single digit. It is a pity; I would also have been interested to see an informed reply but the absence of one wasn't altogether surprising to me.
The additional issue that its hard to give a useful answer.
Use 'perf record -a ... and pktgen' is likely a rather useless reply.
And might even incorrect depending on what one wants to measure.
In general, its best to compact the ruleset as much as possible
and use sets/maps/vmaps wherever possible.
