Re: [PATCH] fine grain locking for tcp helper

[Pablo Neira <pablo@eurodev.net>]

Hi Jozsef,

Jozsef Kadlecsik wrote:

>I'm not conviced that much could be gained with per TCP locking assuming
>normal traffic, predominated by TCP. I'm fairly sure that per bucket
>locking is the way we should go.
>  
>

Actually I was having a look at conntrack_locking for per bucket locking 
some days ago, I find it interesting. I had in mind to port them to 2.6 
but Patrick was faster :-).

BTW, is there any problem in using both patches at the same time? If we 
have a machine with mostly tcp traffic, when we take a conntrack, two 
buckets will be locked (for original and reply tuples), but when calling 
tcp specific functions, it will spin until tcp_lock is released possibly 
by other conntrack.

mmm could this reduce the time both buckets are locked?

>Could you check and revive the patches
>
>conntrack_arefcount	- revised reference counting
>  
>
     ^^^
Is conntrack_locking dependent of this patch? in pom-ng is marked as 
dependent, but I don't understand why.

If there's no real dependency I think that I could only test 
conntrack_locking which is more simple (well, I think), this way we 
could push for kernel inclusion, and after that, go test the revised 
reference counting. Am I missing anything?

>conntrack_locking	- per bucket locking
>[conntrack_nonat	- optimization for the conntrack-only case]
>
>The patches could be pushed forward if there were independent
>success reports for general cases, not just performance test reports.
>  
>
sure, I'll have a look at them :-).

regards,
Pablo