[v3.2.24] ct: endless loop when initializing netfilter/ct cache

[Holger Eitzenberger]

Sorry, I have been interrupted, now going back to this problem.

> > Turns out to be more of like a performance regresssion, as same
> > program built against libnl v3.2.13 is considerably faster - even on a
> > box with more conntracks...

FYI, I see the problem since changing pickup_cb() to check for
duplicates when updating the cache.

The cache->c_items are a list of cache entries, and they are searched
in order for a matching entry in nl_cache_search().

For a mass entity like conntracks this turns out to be very bad on
performance.

This is the program using libnl v3.2.13 (using LD_PRELOAD):

 $ time ct -L 
 real	0m0.164s
 user	0m0.116s
 sys	0m0.044s

And this same binary using libnl v3.2.24:

 real	0m3.416s
 user	0m3.384s
 sys	0m0.028s

With roughly same number of conntracks.

Turns out to be since commit:

 commit 96bb7c9a4cdd10a2665c0f56120943e79e33c560
 Author: roopa <roopa at cumulusnetworks.com>
 Date:   Thu Dec 20 18:32:00 2012 -0800
 
     cache pickup: Avoid duplicates during cache pickup

My change of course is to avoid using the cache in the first place, as
my use-case is mostly "read-once".  However, it still would be nice to
avoid this behaviour on the initial dump.

I'd tend to expect this behaviour only iff cache is maintained after
initial dump.

 /Holger