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

[Thomas Graf <tgraf@suug.ch>]

* jamal <1104330054.1089.329.camel@jzny.localdomain> 2004-12-29 09:20
> Given the opportunity: I think we need to put those flags as well for
> the u32 keys(and other classifiers) so we can have similar logic?

Sounds reasonable and easy to do if we introduce a new selector TLV.
Speaking of the other classifiers:

fw: Currently a list of ORed matches, nfmark transported via handle.
    We could change it to transfer the nfmark via a TLV and implement
    the same logic as in u32 (simple). The problem is mainly how to
    guarantee backwards compatibility, the handle would no longer
    tell about the nfmark being matched. OTOH, fw is no longer needed
    once we have metadata match. Adding a "always-true" classifier with
    ematch extension will completely replace it (except for the old
    path with netfilter disabled).

tcindex: No changes required and partly replaced with metadata match
         but not completely. It would still be perfectly fine to map
         dscp values to classids.  

route4: Also partly replaced with metadata match but we would lose
        the exellent fast paths. We can leave it as-is and have metadata
        match for more complex matches (slow) and route4 for simple but
        fast uses.

rsvp: Could theoretically be replaced with new u32 and extensive use
      of continue/reclassify but that's quite difficult. It's very
      specialized (and currently quite vulnerable to pskbs) and the use
      of it is clearly towards fast flow redirection. No need to change
      this.

So, the conclusion for me is that we can focus on u32 and new
classifiers and eventually make fw obsolete in the future.

> Also in the case of u32 (to take this opportunity) i would like to stash
> state inot a 16 bit ID to help in pretty printing the matches.

Not sure what you mean. Which "state"?

> So if we have an extra 32 bits for flags:ID probably 8 bits for your
> need for flags, 16 bits for private Id and maybe another 8 bit for
> something else like versioning...

Basically what I need is 3 bits for logic relations and at least 8
for precedence index or 4 bits and reuse one of the already existing
fields unused when key is used as container for sub keys. So, 8 bits
will suit me very well.

+---+---+-----+
| I | C |  R  |
+---+---+-----+

I := 1 Match is inverted
     0 Match is straight

C := 1 Container Key
     0 Normal Key

R := 0 0 Last Key
     0 1 AND
     1 0 OR

While we're at it we should increase nkeys to 16bit.