From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Graf Subject: Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier. Date: Fri, 31 Dec 2004 12:08:36 +0100 Message-ID: <20041231110836.GD32419@postel.suug.ch> References: <20041228231916.GG32419@postel.suug.ch> <1104277165.1100.291.camel@jzny.localdomain> <20041229000928.GH32419@postel.suug.ch> <1104282811.1090.314.camel@jzny.localdomain> <20041229124842.GI32419@postel.suug.ch> <1104330054.1089.329.camel@jzny.localdomain> <20041229150140.GJ32419@postel.suug.ch> <1104335620.1025.22.camel@jzny.localdomain> <20041230174313.GB32419@postel.suug.ch> <1104469111.1049.219.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "David S. Miller" , netdev@oss.sgi.com Return-path: To: jamal Content-Disposition: inline In-Reply-To: <1104469111.1049.219.camel@jzny.localdomain> Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com List-Id: netdev.vger.kernel.org * jamal <1104469111.1049.219.camel@jzny.localdomain> 2004-12-30 23:58 > On Thu, 2004-12-30 at 12:43, Thomas Graf wrote: > > * jamal <1104335620.1025.22.camel@jzny.localdomain> 2004-12-29 10:53 > > > > If i store some ID that would tell me "IP" when i dump then i can pretty > > > print it in english in user space using ip_print(). > > > > Understood, we could store a map in userspace mapping those IDs to > > pretty english match descriptions. I think avoiding to hardcode those > > ids but rather just hold it for userspace is the best thing. > > We may be in sync: > I was thinking of just teaching tc to stash something there that it > understands on how to translate. Thinking about it now, this may not > be sufficient: perhaps we need a few bits in the selector to identify > the owner who installed the rule to begin with. Then it would be safe to > interpret the meaning of the ID (by the same app). Did you say there > were some unused bits in the selector? Right, but why not do this in userspace by having a global map somewhere in a file? A u32 config could have been modified by multiple pids and it would get really messy to store a pid for every possible changeable item. > I think all you need really is to say "this match starts at IP" i.e such > a definition is global. > handles per rule already exist - and you can actually specify them when > installing a rule. Are those insufficient? Those are absolutely sufficient. I was thinking of giving a match a 16bit ID which can be used for both, identifying and mapping, i.e: __u8 kind; /* match type, for lookup in matchers table */ __u8 flags; /* Invert Flag + Relations */ __u16 handle; /* must be unique per selector, may be autogenerated */ I want to have those matches be as small as possible, so no nested TLVs but rather this u32 + matcher specific data form a TLV together. A selector consists of a TLV array of such matches. The first TLV, type=1 becomes a header with the possibility to transfer classifier specific options (such as hash table configuration for u32). > Why not make the always-true to be an extended match? actually a u32 > match of 0 0 is always true. Those hashes are quiet tricky/flexible; > i would rather we clone u32 and call it something else then speacilize > it. Agreed, I don't want to change u32 but I want to introduce ematches in u32 as well so we can benefit from the hashing but for those who don't need hashing u32 is already bloat so we can do a simple always-true classifier which does nothing more than evaluating the ematches. I want to have the u32 match be a ematch as well so the always-true classifier would become a u32 alternative but without the hashing overhead. > Both sound very appealing. You plan to do them as extended matches, > correct? Excatly. > KMP can be used for something like virus scanning? does it > maintain state? It requires the following parameters: - start offset - end offset - pattern - prefix table and then will simply start at `start` and scans until `end` looking for pattern with the help of the prefix table. Again, I'm not sure what you mean by state ;->