From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amin Azez Subject: Re: RFC: Disable defered bridge hooks by default Date: Tue, 11 Jul 2006 10:33:23 +0100 Message-ID: <44B37063.90806@ufomechanic.net> References: <44AA3446.6050609@trash.net> <44AA3496.5050909@trash.net> <44AEFE20.3020307@shorewall.net> <44AF200F.9000204@trash.net> <44B22434.3050801@ufomechanic.net> <44B3611D.6030902@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Netfilter Development Mailinglist , Bart De Schuymer Return-path: To: netfilter-devel@lists.netfilter.org In-Reply-To: <44B3611D.6030902@trash.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org Patrick McHardy wrote: > Amin Azez wrote: >> This leads me to suggest addition of ipt_marks instead of ipt_mark >> >> Not only is "the" mark overutilized but the problems of managing free >> bit-ranges in iptables/ebtables (if/when ebtables supports masking) will >> also be too troublesome to bear. >> >> I re-suggest adding multiple on-demand storage slots to conntrack (and >> now also skb's), for storing labelled cookie-type values tor checking >> later, by iptables or ebtables or any-other. >> >> My I copy my latest RFC attempt here (still a work in progress) >> >> [...] >> >> Do these overheads waste any advantage in merely trying to save space in >> the conntrack? >> >> Do this neatly solve the problem of passing state between tables? >> >> Do these overheads waste any advantage in using the conntrack as a >> caching mechanism? > > I would prefer to see some code before commenting. My gut feeling > is that it is overly complex. Have you looked at Rusty's ct_extend? Thankyou for pointing this out. I guess ct_extend is what I am after. And where the extended storage is an integer it ought to be easily available from *_tables. I'll give this a go over. Sam