Re: [RFC] ctnetlink events drop benchmark

[Patrick McHardy <kaber@trash.net>]

Pablo Neira Ayuso wrote:
> Hi,
> 
> Finally, I've got some results in my test enviroment about the ctnetlink
> event drop issue. The machine used as firewall is a PIII 866 256 Mbytes
> RAM, two NIC realtek 8139 100Mbits running debian unstable with linux
> kernel 2.6.16.
> 
> I have run the same test with three different socket queue sizes:
> 107.520 (default)
> 215.040 (x2)
> 430.080 (x4)
> 
> I used netperf to create the connections with a shell script that loops
> calling netperf -H ip -l 3 &.
> 
> To get the number of events dropped I've used the following:
> 
> $ conntrackd & (run as daemon)
> $ conntrackd -s (request statistics)
> 
> Results are available in:
> 
> http://people.netfilter.org/pablo/ctnetlink/events.eps

Does "events" mean events/s?

> Currently nlmsg_seq is not set in ctnetlink events, if we set it, we can
> do some kind of sequence tracking on netlink. If an event gets lost, we
> can request a resync with the conntrack via dump_conntrack.

nlmsg_seq should only (but in that case it really should) be set for
responses to queries, so userspace can associate responses with queries.
Drops are reported as -ENOBUFS socket errors to all multicast listeners.

> Another choice could be relax conntrackd states transitions, currently
> the valid transition sequence is: NEW -> UPDATE -> DESTROY, if an UPDATE
> event is received but no NEW was seen previously, then the event is
> ignored. Maybe this is too tight, but since I'm validating the whole
> thing I prefer remaining "tight" at the moment.

I guess this could be made configurable, but I think for testing
purposes its better to be stricter so it doesn't shadow real
problems.