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

[Thomas Graf <tgraf@suug.ch>]

* jamal <1105105511.1046.77.camel@jzny.localdomain> 2005-01-07 08:45
> > 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).