Re: PATCH: extra conntrack stats

[Rusty Russell <rusty@rustcorp.com.au>]

In message <Pine.LNX.4.33.0304301227530.3328-100000@blackhole.kfki.hu> you write:
> As usual, it's Rusty's locking patch what triggered me to think over the
> locking issues. In that patch Rusty actually eliminates ip_conntrack
> lock:

Ah, but I think I might have a better trick.  Patrick cc'd since he's
the hashing man.

Can we compromise the hash so that every packet hashes to the same
chain as its reply?

If we can do this without making our hash really suck, we only need one
entry per conntrack (and we then compare both ways).  This means a
smaller table, and hence better cache utilization, as well as simpler
locking.

Thoughts?

> I think that eliminating ip_conntrack lock might uncover a (potential)
> bottleneck: the tcp_lock, the lock in conntrack for the predominant
> protocol of the Internet.
> 
> By adding a data lock to the conntrack entries can solve that
> (potential) problem. The data lock would make unnecessary the per
> conntrack helper locks too (unfortunately the buffers introduced in the
> zerocopy patch undo that).

Yeah, per-entry locks make sense I think.  I can change the helpers to
do an skb_copy (suggested by Alexey) which will be lockless, or just
implement the damn non-linear search.

Cheers,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.