lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 18 Mar 2009 15:39:39 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Meelis Roos <mroos@...ux.ee>
CC:	netdev@...r.kernel.org
Subject: Re: [ANNOUNCE]: First release of nftables

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.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ