Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 05:33:01 -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 j04DWXmm015060 for ; Tue, 4 Jan 2005 05:32:53 -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 EA8C682; Tue, 4 Jan 2005 14:40:43 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 70FB71C0EA; Tue, 4 Jan 2005 14:41:26 +0100 (CET) Date: Tue, 4 Jan 2005 14:41:26 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier Message-ID: <20050104134126.GJ26856@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1104844935.1085.103.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.80/645/Mon Dec 27 14:56:20 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 13376 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 <1104844935.1085.103.camel@jzny.localdomain> 2005-01-04 08:22 > On Tue, 2005-01-04 at 07:27, Thomas Graf wrote: > > Many use u32 to match simple stuff as port numbers, dscp values > > or ip subnet addresses and create a new filter for every port/dscp > > value and for every address. Some even use temporary classes to > > emulate logic relations and this gets really slow. I have to get > > numbers first but a single basic filter with ORed matches is probably > > faster than a separate u32 filter for every case. > > I am pretty sure someone who knows u32 well can outperform you (in the > scenarios where u32 works using AND etc). > Start hitting 50K rules then lets talk ;-> Sure but I'd call a filter with 50K ANDed rules an unlikely scenario ;-> In most cases logic will beat brute force. I used to have a u32 setup with 4K matches and hashing, it was not only error prone but could be replaced with 12 egp filters gaining 90kpps. Why's that? Simply because it was easier to optimize the logic behind it. egp itself is terribly slow compared to u32. > If your intent is to write an ematch holder, then it would be worth to > at least go as far as making it some basic hash - as basic as fw does; > where collision leads toa linked list. If it is just to show an example, > then it is fine. Using what key? We have no knowledge about what the ematches want to see or not.