Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Jan 2005 02:06:15 -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 j0AA6AKu013676
	for <netdev@oss.sgi.com>; Mon, 10 Jan 2005 02:06:11 -0800
Received: from mail.cyberus.ca ([209.197.145.21])
	by mx03.cybersurf.com with esmtp (Exim 4.30)
	id 1Co7fn-0001bh-KF
	for netdev@oss.sgi.com; Mon, 10 Jan 2005 17:06:03 -0500
Received: from [216.209.86.2] (helo=[10.0.0.9])
	by mail.cyberus.ca with esmtp (Exim 4.20)
	id 1Co7fS-0001Aq-T7; Mon, 10 Jan 2005 17:05:43 -0500
Subject: Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier
From: jamal <hadi@cyberus.ca>
Reply-To: hadi@cyberus.ca
To: Thomas Graf <tgraf@suug.ch>
Cc: netdev@oss.sgi.com
In-Reply-To: <20050110211747.GA26856@postel.suug.ch>
References: <20050104223612.GN26856@postel.suug.ch>
	 <1104894728.1117.56.camel@jzny.localdomain>
	 <20050105110048.GO26856@postel.suug.ch>
	 <1104931991.1117.152.camel@jzny.localdomain>
	 <20050105144514.GQ26856@postel.suug.ch>
	 <1105019225.2312.7.camel@jzny.localdomain>
	 <20050106194102.GW26856@postel.suug.ch>
	 <1105105511.1046.77.camel@jzny.localdomain>
	 <20050108145457.GZ26856@postel.suug.ch>
	 <1105363582.1041.162.camel@jzny.localdomain>
	 <20050110211747.GA26856@postel.suug.ch>
Content-Type: text/plain
Organization: jamalopolous
Message-Id: <1105394738.1085.63.camel@jzny.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 10 Jan 2005 17:05:38 -0500
Content-Transfer-Encoding: 7bit
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: 57
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 Mon, 2005-01-10 at 16:17, Thomas Graf wrote:
> * jamal <1105363582.1041.162.camel@jzny.localdomain> 2005-01-10 08:26
> > I think its _a hack_ Thomas ;-> Mostly because it has dependency on u32.
> > off2 doesnt exist on any other classifier and the basic ematch should be
> > usable by any classifier.
> 
> It does not, u32 does have a dependency on em_u32 but not vice versa.
> em_u32 is perfectly useful even without nexthdr functionality since
> this is the way it is used today in 90% of the cases and it should be
> a little bit faster than em_cmp but also a bit less powerful. On top
> of that, rsvp could provide this information as well so one could
> extend rsvp with em_u32 ematches. I think we should not think of it
> as being dependant on off2 but rather as it is able to use information
> from a underlying layer.

Ok, you make a convincing arguement ;-> No more concerns from my side.
Churn that code!

cheers,
jamal