Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 15:09:31 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04N93Xj003493 for ; Tue, 4 Jan 2005 15:09:24 -0800 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 6E18B82; Wed, 5 Jan 2005 12:08:34 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 9B15F1C0EA; Wed, 5 Jan 2005 12:09:17 +0100 (CET) Date: Wed, 5 Jan 2005 12:09:17 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier Message-ID: <20050105110917.GP26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <1104812028.1085.50.camel@jzny.localdomain> <20050104122738.GG26856@postel.suug.ch> <1104844935.1085.103.camel@jzny.localdomain> <20050104134126.GJ26856@postel.suug.ch> <1104893694.1124.37.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104893694.1124.37.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13412 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * jamal <1104893694.1124.37.camel@jzny.localdomain> 2005-01-04 21:54 > I think this is a debate that can be easily settled ;-> > Agreed logic will beat brute force smartness and u32 is not exactly > for the faint hearted. And its usability is extremely poor - but lets > maintain its power as is. Absolutely. > > Using what key? We have no knowledge about what the ematches want to > > see or not. > > Ok, good question ;-> > Maybe you should have own some 32 bit key? Actually the goal of basic is to be an alternative to u32 if hashing is not required because I think adding hashing will simply result in a duplication of u32.