Received: with ECARTIS (v1.0.0; list netdev); Wed, 05 Jan 2005 18:04:16 -0800 (PST)
Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105])
	by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j0624BBn007576
	for <netdev@oss.sgi.com>; Wed, 5 Jan 2005 18:04:12 -0800
Received: from mail.cyberus.ca ([209.197.145.21])
	by mx02.cybersurf.com with esmtp (Exim 4.30)
	id 1CmYF7-0000u8-C7
	for netdev@oss.sgi.com; Thu, 06 Jan 2005 09:04:01 -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 1CmYF5-0001ps-DH; Thu, 06 Jan 2005 09:03:59 -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: <20050105164832.GB17836@postel.suug.ch>
References: <20050103125635.GB26856@postel.suug.ch>
	 <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>
	 <20050105164832.GB17836@postel.suug.ch>
Content-Type: text/plain
Organization: jamalopolous
Message-Id: <1105020237.2314.26.camel@jzny.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 06 Jan 2005 09:03:57 -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: 13460
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 Wed, 2005-01-05 at 11:48, Thomas Graf wrote:

> Here's what I mean, it moves the u32 match as-is to an ematch so it
> benefits from logic relations, inversion and can be used from other
> classifiers as well. All we have to do is set info->ptr and
> info->nexthdr to ptr respetively off2 before we evaluate the ematch
> tree. The pkt_info struct is then passed to tcf_em_tree_match and
> made available to every ematch.
> 
> Thoughts?

I think this is fine; getting into complicated-land with off2 etc but
fine and does not preclude (and is lower importance in my opinion) than
having u32 do its own magic. 
Note again Thomas: I do realize its more work to do the ematch/match
thing ;->

cheers,
jamal