Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Jan 2005 05:14:14 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j04DDljL013816 for ; Tue, 4 Jan 2005 05:14:07 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1Clodf-0004hI-R8 for netdev@oss.sgi.com; Tue, 04 Jan 2005 08:22:19 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Clode-0002YX-EY; Tue, 04 Jan 2005 08:22:18 -0500 Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: <20050104122738.GG26856@postel.suug.ch> References: <20050103125635.GB26856@postel.suug.ch> <1104812028.1085.50.camel@jzny.localdomain> <20050104122738.GG26856@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1104844935.1085.103.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Jan 2005 08:22:15 -0500 Content-Transfer-Encoding: 7bit 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: 13375 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2005-01-04 at 07:27, Thomas Graf wrote: > * jamal <1104812028.1085.50.camel@jzny.localdomain> 2005-01-03 23:13 > > Very inefficient, but serves the purpose of an example. > > [Even if you go as basic a hash as fw classifier you will do better] > > Might be worth to mention the motivation for this. fw and u32 > will definitely perform much better on complex setups but > many do not use u32 hashing not to mention even understand it > or have large nfmark -> classid fw maps. agreed. > 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, once u32 > has ematch support it gets better and the hashing shouldn't have > too much influence even if it's unused.. We can see what to do once > u32 can handle ematches. 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. cheers, jamal