Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier.

[Thomas Graf <tgraf@suug.ch>]

* 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.