On Tue, 2004-12-28 at 17:10, Thomas Graf wrote:
> * jamal <1104268498.1090.254.camel@xxxxxxxxxxxxxxxx> 2004-12-28 16:14
> > Whatever you had before is fine for action/policer - with intent to kill
> > policer eventually.
>
> I left it in for now but I see no reason why to do so actually. Old
> iproute2 binaries should do just fine with the action backward
> compatibility code?
>
Its maintainance work. Nothing it provides isnt provided by
new policer.
> > What i objected to is the indev and any other thing that has to do with
> > classification helping - thats not where it should fit.
> > Take u32 for example: The fit for match extensions is really at the key
> > level not at a layer above.
> > We need a sel2 which has new keys (which is easy because thats
> > transported in a TLV).
>
> Take a look at http://people.suug.ch/~tgr/patches/queue/03_tcf_exts_u32.diff
>
> The extensions are on the same level as the selector.
Ok, i see we may be talking about two separate things:->
that patch is fine for policer/action (I noticed you removed indev -
good thing).
It is not proper spot for the matches and infact
should go in as a separate patch altogether (relation is very minimal).
For the matches, the checks are going to be per key _not_ at the
selector level; i.e:
struct tc_newu32_key
{
__u32 mask;
__u32 val;
int off;
int offmask;
pointer to extendedmatches here.
};
Since these keys are packed in a selector and the selector is what gets
transported from/to user space we need a selector2 which packs these new
keys instead. Makes sense? i.e need a TCA_U32_SEL2 where the extended
matches are stored.
Backward compatibility: New TC transports them in addition to
TCA_U32_SEL and old kernels ignore them.
old TC doesnt send them so new kernels can handle them just fine. Beauty
of TLVs.
Your check in the classifier is
if (matched) {
if (NULL != key.pointertoematch) {
ret = call the generic ematch function
if ret == OK
continue with next match
else failed
}
}
u32_change receives the extended matches and populates them accordingly.
There is no need for a dump fucntion to exist for them. They get shipped
back the same way they came in - user space knows how to dump them.
a key.pointertoematch could be infact a llist of these items. So the
struct looks like:
struct tcf_ematch_info
{
struct tcf_ematch_info *next;
__u32 type
void *data;
may need a datalen here for dumping back to user space.
};
Makes sense?
Back to what i said earlier i can now write a single page of code
to scan for word "Thomas" if i get a match on TCP port 25 for all IP
addresses... i.e metadata is a subset of all this.
cheers,
jamal
|