Re: patch for conntrack expectations

[Pablo Neira <pablo@eurodev.net>]

Harald Welte wrote:

>This is indeed a true observation and good suggestion. 
>
>Hoever, I'm not sure whether it would make any measurable difference.
>The expect was allocated on the stack [which is cheap], and now we have
>one additional (inter-module) function call instead of the allocation of
>a couple of bytes on the stack.  I'm not sure which one is really worse.
>  
>
well, sorry because I'm going to be a bit repetitive but this way 
everyone's going to understand my patch clearly.

in some steps:

1) helper function is called
2) a pointer to a ip_conntrack_expect structure is allocated on the stack
3) if the pattern which we are looking for is *not* found
    -> return NF_ACCEPT
4) else
    -> a ip_conntrack_expect structure is allocated in memory
5) all the fields of the expectation are fulfilled
6) helper calls ip_conntrack_expect_related to insert the expectation
but it passes a pointer to a structure allocated in memory.

what's the different between this approach and the current one?

If the pattern which we are looking for is not found, nothing will 
change, we just allocated less memory on the stack but of course this 
doesn't improve the performance, so it's the same.

By other hand, in the current approach if the pattern is found, the 
function ip_conntrack_expect_related does a memcpy of a structure of 116 
bytes (expectation) from the stack to memory. This is not needed anymore 
since with the new approach the helper works with the future expectation 
already allocated in memory.

I also think that this will result in a cleaner API to manage the 
expectations. well, maybe you could also use this to allocate an 
expectation for the connection tracking replication (well... i just 
started talking so much).

>Also, 2.4.x kernel series are heading for a freeze pretty soon.
>  
>
yes it's true

>So if at all, such a patch would be accepted for 2.6.x.  But then I
>would like to ask you to change all the helpers (esp. the ones in
>patch-o-matic-ng), too.
>  
>
I had a look at almost all the helpers which are in patch-o-matic-ng 
(even the pptp helper). I have no problem about modifying them. BTW, the 
documentation should be updated as well if this change is applied.

Pablo