Pablo Neira Ayuso wrote:
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?
The part that supresses conntrack events seems useful, why not simply split it in a seperate module? It would be even more useful if we had a match to match on conntrack protocol states I guess. - 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
