Re: ctnetlink questions

[Patrick McHardy <kaber@trash.net>]

Harald Welte wrote:

>On Mon, Oct 20, 2003 at 05:01:17AM +0200, Patrick McHardy wrote:
>
>>- we can use some sorting algorithm which benefits from pre-sorted 
>>input. this would give better average performance. IIRC new conntracks
>>are added at the head of the chains, so if we sort and walk backwards
>>through the chains we only have to resort after an id counter wrap.
>>    
>>
>
>this works with a 64bit counter, but doesn't with my proposed generation
>counter.  the generation counter has two advantages:
>- no global counter, just the counter field in every conntrack
>- less size increase of struct ip_conntrack. 
>
>Oh well, yes.  We have to think about the slab cache returning objects
>to the 'real' memory allocator.  Then our generation counter would
>become useless.  Don't know if it is reliable enough to initialize the
>counter with a random 32bits in that case.  How high is the  probability
>of re-using the recently-used counter in that case?
>

Actually with 64 bit the wrap-around time is so large we would never 
have to resort.

>>I agree, we should use 64 bit.
>>    
>>
>
>I feel like I have to cry.  As soon as we add any kind of counter (be
>it 32 or 64 bits), we would definitely have to make it a compile time
>option.  My vision of ctnetlink was something like a match extension:
>You can always compile it as a module, and it wouldn't hurt performance
>as long as you don't load it.
>  
>

I understand your objections, It is really not my intend to enlarge 
struct ip_conntrack without
the need to do so. However I'd rather save some memory by f.e. making 
helper memory
dynamic than by saving these couple of bytes and making some 
functionality of ctnetlink
somewhat useless. Compiling as a module without performance penalty 
won't work anyways
as soon as you enable event notifications.

So do I understand correctly we're at the point were we agree we need to 
add something
to struct ip_conntrack and either use a linear increasing global counter 
or a generation count
which increases as soon as we return something to the slab.

Advantages/Disadvantages of global counter:
- don't need any sorting with 64bit, natural sorting is fine
- uniquely identifies conntracks without risk of collisions
- possible contention on global counter

Advantages of generation count:
- No global counter
- probably expensive sorting needed over time
- no unique identity, can not be used from userspace

I still favour the global counter but I'm fine as long as dumping works, 
a unqiue identity for
userspace is less important. I'd say it's up to you to decide.

Best regards,
Patrick