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

* jamal [ref] 2005-01-07 08:45

quoted

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. 

What's the reason for not liking it? I know it's not a perfect solution
in terms of layers but having the classifier sharing already gathered
information to an ematch is not a bad thing.

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 easiest way is to introduce a new TLV type and regard configuration
requests carrying the old type in compatibility mode.

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.

Given we always use the new method by converting old style parameters
and we use em_u32 as u32 key we would need to put a dependcy on ematch
&& em_u32 for cls_u32.

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?

I won't and it's not necessary, one can use u32 if he requires the
nexthdr capabilities or otherwise use em_cmp support the skb layers.
(Which i know is not perfect since the pointers to those layers are
not provided all the time).