Re: Advantage(s) of static over dynamic nftables sets?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Frank Myhr <fmyhr@xxxxxxxxxxx> wrote:
> > > Would performance and/or memory usage take a significant hit by
> > > [defining all sets dynamic]?
> > 
> > I don't think so, but this will probably depend a lot on the
> > system in question and on the type of elements stored.
> 
> Makes sense, thanks. I suppose efficiency gets progressively worse for
> element types with larger possible ranges (# of bits), something like?:

Right now (assuming static), size <= 16 bits is most efficient,
then <= 32 bit, rest uses hash table.

> I suppose intervals are more efficient than an equivalent group of single
> elements?

Memory-wise yes, performance-wise no.

> Is a concatenation like ipv4_addr . inet_service as efficient as a pure data
> type with the same number of bits?

Yes, as it makes no difference for the storage.  The kernel doesn't know
what its storing, it only knows the size of the element.

It does store a 'type' information, but that is only used by nftables
so it knows how to format the elements when listing the ruleset.



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux