From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: 2.6.20 support for other 'features' Date: Fri, 13 Apr 2007 06:22:29 +0200 Message-ID: <461F0585.9030103@trash.net> References: <461D2033.2030508@trash.net> <461D2748.4050000@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: netfilter-devel@lists.netfilter.org To: Mohammad Mohsenzadeh Return-path: In-Reply-To: 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 Mohammad Mohsenzadeh wrote: > On 4/11/07, Patrick McHardy wrote: > >> And how would it do that for two external modules, that don't know >> how large the last part is? >> > > That's absolutely correct. How about having only one slab cache and a > dynamic list of features. Whenever a new feature is registered or an > old one is removed, we can reallocate slab cache with a new size. I'm > not sure if that would work for sure, just throwing some ideas out > there. Something like > > [...] > One problem that I can see with this is that we have flush all our > conntracks so we can call kmem_cache_destroy and then recreate the > slab with new size. Would this be alright since it would only happen > on registering and unregistering features since it doesn't happen > often. No, I don't like that, besides a single slab cache would force us to waste space by always allocating the maximum size even if not needed for a specific conntrack (helpers for example are rare). Rusty had a better idea, search the archives for ct_extend.