From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [RFC nf-next-2.6] conntrack: per cpu nf_conntrack_untracked Date: Fri, 04 Jun 2010 14:29:24 +0200 Message-ID: <4C08F1A4.2050906@trash.net> References: <1271941082.14501.189.camel@jdb-workstation> <4BD04C74.9020402@trash.net> <1271946961.7895.5665.camel@edumazet-laptop> <1271948029.7895.5707.camel@edumazet-laptop> <20100422155123.GA2524@linux.vnet.ibm.com> <1271952128.7895.5851.camel@edumazet-laptop> <1272056237.4599.7.camel@edumazet-laptop> <1272139861.20714.525.camel@edumazet-laptop> <1272292568.13192.43.camel@jdb-workstation> <1275340896.2478.26.camel@edumazet-laptop> <1275368732.2478.88.camel@edumazet-laptop> <4C04DE73.6050605@trash.net> <1275388310.2738.2.camel@edumazet-laptop> <4C04E3E2.702020 9@trash.net> <1275409203.2738.227.camel@edumazet-laptop> <4C08E62A.9020607@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Eric Dumazet , Netfilter Developers , netdev To: Changli Gao Return-path: In-Reply-To: Sender: netfilter-devel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Changli Gao wrote: > On Fri, Jun 4, 2010 at 7:40 PM, Patrick McHardy wrote: >> Eric Dumazet wrote: >>> Obviously, an IPS_UNTRACKED bit would be much easier to implement. >>> Would it be acceptable ? >> That also would be fine. However the main idea behind using a nfctinfo >> bit was that we wouldn't need the untracked conntrack anymore at all. >> But I guess a per-cpu untrack conntrack would already be an improvement >> over the current situation. > > I think Eric didn't mean ip_conntrack_info but ip_conntrack_status > bit. Since we have had a IPS_TEMPLATE bit, I think another > IPS_UNTRACKED bit is also acceptable. Yes, of course. But using one of these bits implies that we'd still have the untracked conntrack.