On Sat, 2005-01-01 at 13:32, Thomas Graf wrote:
> OK, I changed my mind while implementing it and a selector now looks
> like this:
>
> Selector TLV:
>
> +----------------------------+
> | TCA_EMATCH_TREE_HDR |
> +----------------------------+
> | TCA_EMATCH_TREE_LIST |
> | +------------------------+ |
> | | T=1 Match 1 | |
> | +------------------------+ |
> | | T=2 Match 2 | |
> | +------------------------+ |
> | | T=N Match N | |
> | +------------------------+ |
> +----------------------------+
>
what happened to the good old SEL TLV (which i believe we called SEL2
now); or maybe thats what contains this TLV?
> So we can put more into the selector if needed without breaking
> compatibility. TCA_EMATCH_TREE_HDR currently contains `nmatches'
> specifying N and progid holding the PID you talked about.
Ok, so i think you may be saying the old selector stays intact then
(sans the matches)?
Why do you need to specify "nmatches".
You know exactly where each one starts and ends (from the TLVs).
What is TCA_EMATCH_TREE_LIST for? Looks like another TLV nesting. Not
needed, you just plumb the T=1,..T=N right after the header.
> The match TLVs must have a continous numbering because I don't
> want to define limits as done in the action code.
I think the way you have it is fine - and believe it is the way the
action code has it for the list.
> I'll post an RFC patch tomorrow implementing the API and a
> simple ematch.
Nice. I have started implementing the eaction code but too obsessed with
this other thing i am working on - hopefully i will get to it before my
vacation expires.
cheers,
jamal
|