From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [RFC] Die to NOTRACK/TRACE, long live MARK! Date: Sat, 22 May 2004 16:57:36 +0200 Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: <40AF6A60.70406@trash.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Philip Craig , Jozsef Kadlecsik , netfilter-devel@lists.netfilter.org Return-path: To: Jozsef Kadlecsik In-Reply-To: Errors-To: netfilter-devel-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Id: netfilter-devel.vger.kernel.org Jozsef Kadlecsik wrote: > Hm. Actually, as we already use a bit in nfcache for TRACE, we could > reserve bits generally: > > #define NFC_HOOKS_MASK 0x0000FFFF > #define NFC_FLAGS_MASK 0xFFFF0000 > > /* Special netfilter flags */ > > #define NFC_PKT_FLAGS_MASK 0x00FF0000 > #define NFC_CT_FLAGS_MASK 0xFF000000 > > #define NFC_FLAG_TRACE 0x00010000 > #define NFC_FLAG_NOTRACK 0x00020000 > #define NFC_FLAG_CT_TCP_SYNRST 0x01000000 > > The lower half could be manipulated by MARK while the upper half by > CONNMARK. But the latter would require a new element in ip_conntrack > itself and I wouldn' really like to make it bigger. I like the idea for MARK, but why should we manipulate nfcache from CONNMARK, and not let the users of the bits get them directly from struct ip_conntrack (f.i. CT_TCP_SYNRST). > Do we really need an unsigned long to store the status? :-) I always thought we would, because set_bit and test_bit take unsigned long *, but I'm not sure anymore if that really means we can't use something smaller. But good news, I'm currently busy shrinking struct ip_conntrack (I bet myself I could shrink it 30% within 24 hours). I'm already at 28% ;) -8bytes replacing struct ip_nat_hash by struct list_head because of two saved conntrack pointers -20bytes replacing struct nf_ct_info array by new value in struct sk_buff indicating relation between skb and conntrack .. maybe we could also put this in nfcache. -56bytes dynamically allocating helper data, but crashes with NAT atm I see 4 more bytes by using u_int16_t for initialized and num_manips in struct ip_nat_info, and maybe I can also squeeze masq_index in there. > > >>PS: Joszef, I changed your address to @netfilter.org, your mailserver >>doesn't like me. > > > I whitelisted you, sorry for the inconvenience. Thanks. Regards Patrick