Re: [PATCH 4/4] first conntrack ID must be 1 not 2

[Patrick McHardy <kaber@trash.net>]

Jozsef Kadlecsik wrote:
> On Thu, 16 Feb 2006, Patrick McHardy wrote:
> 
>>Actually it would still not be unique if connections live
>>shorter than a jiffy and are resurrected.
> 
> 
> I can imagine such a situation only when the conntrack table is full and
> we are forced to drop unassured connections - when we are in trouble
> anyway.

I guess it depends on how fast the everything is. Someone at the
workshop made the point that given how fast speed increases, it
will probably be a realistic problem at some point. But I was
never convinced of the current half-assed approach to a unique ID
anyway, its either unique or its not. So in my opinion, we could
eliminate it if we find a better solution for the dumping problem.

>>>Some clever solution should only be found to spread the expectations
>>>over multiple, separatedly locked buckets...
>>
>>I've talked to Harald about this and as a start we can start by
>>allowing masks only for the source part of the tuple. That
>>means we can hash by destinations.
> 
> 
> That's actually fine! Now I should complete that hashtrie/hashtable
> testing I have been planning...

I wanted to work on the expectation lookup thing soon, I'll let you
know once I have something working.