Received: with ECARTIS (v1.0.0; list netdev); Sun, 16 Jan 2005 07:38:08 -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 j0GFc3rX008980
	for <netdev@oss.sgi.com>; Sun, 16 Jan 2005 07:38:03 -0800
Received: from mail.cyberus.ca ([209.197.145.21])
	by mx03.cybersurf.com with esmtp (Exim 4.30)
	id 1CqCTZ-0007UF-5W
	for netdev@oss.sgi.com; Sun, 16 Jan 2005 10:38: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 1CqCTV-0001lY-RB; Sun, 16 Jan 2005 10:37:58 -0500
Subject: Re: [RFC] meta ematch
From: jamal <hadi@cyberus.ca>
Reply-To: hadi@cyberus.ca
To: Thomas Graf <tgraf@suug.ch>
Cc: Patrick McHardy <kaber@trash.net>, netdev@oss.sgi.com
In-Reply-To: <20050116150914.GU26856@postel.suug.ch>
References: <20050108145457.GZ26856@postel.suug.ch>
	 <1105363582.1041.162.camel@jzny.localdomain>
	 <20050110211747.GA26856@postel.suug.ch>
	 <1105394738.1085.63.camel@jzny.localdomain>
	 <20050113174111.GP26856@postel.suug.ch> <41E6C3E5.2020908@trash.net>
	 <20050113192047.GQ26856@postel.suug.ch> <41E71CC4.3020102@trash.net>
	 <20050114151407.GR26856@postel.suug.ch>
	 <1105887519.1097.597.camel@jzny.localdomain>
	 <20050116150914.GU26856@postel.suug.ch>
Content-Type: text/plain
Organization: jamalopolous
Message-Id: <1105889874.1090.613.camel@jzny.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 16 Jan 2005 10:37:54 -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: 310
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 Sun, 2005-01-16 at 10:09, Thomas Graf wrote:

> The lvalue will be TCF_META_ID_INDEV and your rvalue will be
> TCF_META_TYPE_VAR with "eth0" as payload(TCF_EM_META_RVALUE).
> TCF_EM_META_LVALUE will be unused in this case.

ok - i get it. So the rvalue is basically just the data that needs to be
compared against. rvalue confused me a little. If you had called it
meta_data i would have got it right away. But now that you explain it,
makes sense. 

I am not sure iam following yet:

So in the case of indev, you would need to 
- get indev ifindex from skb
- get indev name from skb
- compare the two??

Actually it may be a little overkill to have those two as separate
entities with their own headers etc, no? Why not just store it in the
same fashion you transported it from/to user space? 

I will start looking at the code

cheers,
jamal