Hi Patrick, Attached an untested RFC patch to discuss the posibility of introducing a generic CONNTRACK target which replaces several existing specific targets. It's a quick and dirty hack. I have also somehow merged the recent Phil Oester's proposition on manual timeouts. We may also introduce there the explicit helper tracking via iptables that you've been discussing lately. Also, I'd like to discuss some kind of mechanisms to reduce the number of event messages generated by ctnetlink such as introducing IPCT_VOLATILE to explicitly tell ctnetlink ignore certain events via iptables. I think that, ideally, an alternative can be some kind of ctnetlink filtering based on unicast netlink socket (similar to nfnetlink_queue) in which we attach a filter via CMD_SUBSCRIBE_EVENTS or something. This solution let us define a per-socket filter in the style of BSF. However, this means that we'll need a complete filtering facility for ctnetlink to classify events, and iptables already provides such classificator. This is intended to reduce the CPU consumption of conntrackd (around 25% avg, 45% max, in my testbed [1] with 2500 HTTP GET request per second) by only replicating TCP ESTABLISHED states. Any ideas? [1] http://people.netfilter.org/pablo/conntrack-tools/testcase.html -- "Los honestos son inadaptados sociales" -- Les Luthiers - To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
