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

[Thomas Graf <tgraf@suug.ch>]

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