Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier

On Thu, 2005-01-06 at 14:41, Thomas Graf wrote:

* jamal [ref] 2005-01-06 08:47

[..]

If we do everything as ref we'll be allocating 4 byte chunks or we
introduce a storage u32 which pollutes the structure. I don't
like that given that the transfer of a single u32 is probably the
most common for all those smallish ematches for a specific thing.
For simplicity, you don't even notice if you're not aware of that
it can be of help so I don't think we're losing any simplicity here.

I am not sure the optimization for a single u32 as the ematch data is
valid ;-> But this is not a show stopper, i will wait for the code to
see if its an annoyance or tolerable.

Missunderstanding here, I meant is there any advantage in having
multiple ematch trees (interleaved) over just making the existing
u32 key an ematch and have the selector (with the hashing bits
extracted) with one ematch tree.

Misunderstanding is the right description.
If you did a s/ematch/match for the u32 part then we'd be shooting for
the same thing;-> So i take back what i said, you are not gonna mess up
the u32 tree logic.

1) extract hashing bits out of selector and move it into a new
   TLV.
2) Replace the foreach key match loop with an ematch_tree match

This is our contention point.

3) Fill out a pkt_info struct with ptr and off2 so we don't lose
   hashing capabilities

And this is why i dont like it. 

4) Add backward compat code. Old selector must be transformed
   into a flat ematch tree and the hashing bits must be extracted
   and stored in the new struct.

I think the u32 changes are one-shot if you want to avoid lotsa #ifdefs.
Someone sends you a old sel, then convert it to a new one for storage.
Dumping is a little trickier, need some way to recognize old style
request. 

The most difficult part is to do the Kconfig dependencies in a smart way ;->

The trick would be to always use sel2 and present no kconfig options for back 
compat. We need to figure out how to recognize an old style dump and we are
set.

quoted

Again, u32 classifier is not just matches; the more interesting thing
is  the layout of the rules that it can be taught to do.
I think the ematch which emulates the std u32 match is of course
valuable to have but it _doesnt_ deserve the same name.

Stupid terms, em_u32.c is a replacement for the u32 key and it has exactly
the same behaviour. I'll be happy to rename it but as you know I really
suck at naming things ;->

em_u32 sounds better ;->
Above you are trying to insert off2 into the info (what i said i didnt
like) - how are you going to achieve the same with a standalone en_u32
from say you basic classifier?

quoted

Thinking more about it; not sure why you would even bother managing
them. Everything runs at the same kernel privilege level. I am not sure
you want to have certain things that can only be built when recompiling
the kernel

Well, we have exactly the same issues as with TLV types. I don't see
why one would need to recompile things. The enumeration is for ematches
included in the kernel tree.

Your call. Actions do it the way i described it. It is more flexible in
my opionion, nothing reserved. Good practise is to know who uses what
(not hardcoding in headers) and the register will catch any discrepancy.

cheers,
jamal