netdev - Re: [PKT_SCHED]: Add stateless NAT

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:	Fri, 28 Sep 2007 18:55:32 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	David Miller <davem@...emloft.net>
CC:	hadi@...erus.ca, herbert@...dor.apana.org.au,
	netdev@...r.kernel.org, kuznet@....inr.ac.ru
Subject: Re: [PKT_SCHED]: Add stateless NAT

David Miller wrote:
> From: jamal <hadi@...erus.ca>
> Date: Thu, 27 Sep 2007 08:39:45 -0400
> 
>>>+config NET_ACT_NAT
>>>+        tristate "Stateless NAT"
>>>+        depends on NET_CLS_ACT
>>>+        select NETFILTER
>>
>>I am gonna have to agree with Evgeniy on this Herbert;->
>>The rewards are it will improve performance for people who dont need
>>netfilter.
> 
> 
> I agree that we should move the functions out.   However...
> 
> You have to realize that this logic is a complete crock
> of shit for %99.99999999999999999999 of Linux users out there
> who get and only use distribution compiled kernels which are
> going to enable everything anyways.
> 
> So we better make sure there are zero performance implications at some
> point just for compiling netfilter into the tree.  I know that isn't
> the case currently, but that means that we aren't helping out the
> majority of Linux users and are thus only adding these optimizations
> for such a small sliver of users and that is totally pointless and
> sucks.

The hooks themselves actually shouldn't be that much of a problem
since without any registered users they come down to a simple
list_empty check. The bigger problem is probably the fact that
the "okfn" is usually declared inline, but we also take its address
for nf_hook_slow, so at least with forced inlining, we end up
with one inlined and one out-of-line version.

Looking at ip_input.o as example (everything without forced inlining):

   text    data     bss     dec     hex filename
   2076       8       0    2084     824 net/ipv4/ip_input.o
   3483       8       0    3491     da3 net/ipv4/ip_input.o

So we have roughly 1.75 more code for the two hooks. For reference,
without using the function pointer it increases a lot less:

   text    data     bss     dec     hex filename
   2319       8       0    2327     917 net/ipv4/ip_input.o

similar with not inlining ip_rcv_finish() and ip_local_deliver_finish():

   text    data     bss     dec     hex filename
   2282       8       0    2290     8f2 net/ipv4/ip_input.o

Any ideas how to do this better? Unforunately we need the function
pointers for reinjecting queued packets ..
-
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