Re: [ANNOUNCE]: First release of nftables

[Patrick McHardy <kaber@trash.net>]

Meelis Roos wrote:
>> Data is represented in a generic way inside the kernel and the
>> operations are defined on the generic data representations, meaning
>> its possible to use any matching feature (ranges, masks, set lookups
>> etc.) with any kind of data. Semantic validation of the operation is
>> performed in userspace, the kernel doesn't care as long as the
>> operation doesn't potentially harm the kernel.
> 
> This sounds like a "script" downloaded to kernel and interpreted during 
> each packet match. This toubles me some - doesn't this use more memory 
> accesses to achieve the same work that was done in precompiled code before?

What makes you think your current ruleset is precompiled?

> Have you measured the fastpath performance of kernel matching of 
> real-life rulesets, compared to iptables?

Yes, but its not a 1:1 comparison. By inlining common operations
(small comparisions, small alignned data loads) in the evaluation
function, costs for a "normal" rule become comparable to iptables.
As soon as you start actually using some of the new stuff, the
comparison doesn't hold anymore. A set, even using rbtrees, which
have a huge overhead in this case, is *a lot* faster than using the
equivalent linear classification rules beginning with a quite small
number. Similar, if you replace 200 rules
"-m realm --realm X --CONNMARK --set-mark X" by a single one, it
will obviously be faster.

On top it has far smaller code and less memory usage as soon as
you have more than one CPU, its lockless, no default counters,
no overhead for unused chains, etc etc.

When the time has come, I will of course post benchmarks.