From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [RFC] generic CONNTRACK target Date: Tue, 15 Jan 2008 07:42:50 +0100 Message-ID: <478C55EA.1070506@trash.net> References: <478B8B74.3070903@netfilter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Phil Oester , Netfilter Development Mailinglist To: Pablo Neira Ayuso Return-path: Received: from stinky.trash.net ([213.144.137.162]:62670 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752170AbYAOGm5 (ORCPT ); Tue, 15 Jan 2008 01:42:57 -0500 In-Reply-To: <478B8B74.3070903@netfilter.org> Sender: netfilter-devel-owner@vger.kernel.org List-ID: 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.