* jamal <1104469111.1049.219.camel@xxxxxxxxxxxxxxxx> 2004-12-30 23:58
> On Thu, 2004-12-30 at 12:43, Thomas Graf wrote:
> > * jamal <1104335620.1025.22.camel@xxxxxxxxxxxxxxxx> 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 ;->