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 16:39:30 +0100 Message-ID: <20041231153930.GN32419@postel.suug.ch> References: <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> <20041231110836.GD32419@postel.suug.ch> <1104505142.1048.262.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: <1104505142.1048.262.camel@jzny.localdomain> Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com List-Id: netdev.vger.kernel.org * jamal <1104505142.1048.262.camel@jzny.localdomain> 2004-12-31 09:59 > On Fri, 2004-12-31 at 06:08, Thomas Graf wrote: > > * jamal <1104469111.1049.219.camel@jzny.localdomain> 2004-12-30 23:58 > > > > 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. > > The "PID" is per app - same as it is for rtm where the different known > routing apps like zebra are given an ID and certain IDs are left blank > for general use. So if you run multiple tcs they will all have the same > ID. The way the id is used in the rtm historically has been for allowing > multiple route protocols to install route entries (this way for example > OSPF does/nt announce RIP routes etc). In our case this would mean: > "this rule was installed by tc - only it knows what the opaque value > 10 means". In that case tc would be responsible to decode 10 which would > mean to it "this is an ip match therefore use ip_print() to pretty > print" and 10 is global to tc only and in that case stored in some > header file belonging to tc. Exactly so we don't need any PIDs stored. /etc/iproute2/tc_matches. > > __u8 kind; /* match type, for lookup in matchers table */ > > 255 possible matchers max? 256 not enough? > > __u8 flags; /* Invert Flag + Relations */ > > __u16 handle; /* must be unique per selector, may be autogenerated */ > > Ok this is the one used to store the opaque IDs - unique per app > so may be the same across multiple selectors. No, it must be unique, we will return EINVAL if it isn't. Most apps will set it to 0 which will autogenerate it with a generate && !get just like in u32. > Probably steal a few bits from here and use them in nkind. Fair, we can also steal a few bits from flags although I'd like to keep at least 3 empty. > Maybe i misunderstood you. You are going to have: > > SEL2 > | > | > +--match1 > | | > | + -- extended match1 > . . > . . > . . > . +---- extnded matchn > | > +--- matchn > > > Why does the first one have to be speacial? No, I'm going to have everything be ematches. > One of the mistakes in u32 is the tight packing of the matches. ie the > match1-n above are packet together. If they were put in TLVs probably > only new thing that will be needed is MATCH2 TLV. > No harm in transporting an extra 32 bits for a TLV - its not like you > are going to have a million matches and need to save space. > So i would suggest everything under a TLV (SEL2->MATCH(ES)->EMATCH(ES)) SEL2: TLV (TCA_U32_SEL2) +-------------------+ | Selector header | +-------------------+ | Match 1 TLV | +-------------------+ | ... | +-------------------+ | Match N TLV | +-------------------+ where Match TLV: +--------------------+ | Match Header (u32) | +- - - - - - - - - - + | Match Data | +--------------------+ Where Header: u8 kind; u8 flags; u16 handle; (or some more for kind and less for handle) where kind := { 0 | match type } handle := { 0 | unique } where kind == 0 means that the match is a container and data contains a u32 pointing into the match array. where kind != 0 means a match to be looked up in the matcher ops table. with the following matches: - u32: {u8|u16|u32} at offset match - meta - kmp - nbyte - ... In case SEL1 TLV is provided we simply create a flat index with no containers and all AND relations. Which means we can do: Sel2 \__match u32 at 2 16 0xff | + and match meta nfmark 2 | + and container \__match u32 at 4 11 0xf0 | + or nbyte "::1" at 12 Thoughts? > A virus would span several packets. So the state/knowldge of whether > something is a virus is spread across several packets. That knowledge > typically needs to be accumulated before making a call. Is this thing > capable of remembering? Not and I would rather do it outside in a separate ematch to match stateful information. I have to think some more about this though.