Hello Oliver,

Oliver Hartkopp [off-list ref] writes:

Hello Rostislav, hello Eric,

On 12.06.2012 16:50, Rostislav Lisovy wrote:

quoted

On Tue, 2012-06-12 at 16:33 +0200, Eric Dumazet wrote: 

quoted

On Tue, 2012-06-12 at 16:03 +0200, Eric Dumazet wrote:

quoted

On Tue, 2012-06-12 at 15:48 +0200, Rostislav Lisovy wrote:

quoted

em_canid is an ematch capable of classifying CAN frames according to
their CAN IDs.

This RFC/Patch contains a reworked classifier initially posted in
http://www.spinics.net/lists/netdev/msg200114.html
The functionality is the same however there is almost 50% reduction
in the source code length.

There is a slight difference between this ematch and other available
ematches. Other ematches implement only a simple match operation and
are meant to be combined with logic conjunctions (e.g. AND, OR).
Our ematch makes it possible to use up to 32 rules in single
'configuration statement' (with OR semantics). This allows us to take
the advantage of the bit field data-structure in the implementation of
the match function.

Example: canid(sff 0x123 eff 0x124 sff 0x230:0x7f0)
This ematch would match CAN SFF frames with the following IDs:
0x123, 0x230--0x23f or EFF frame with ID 0x124.

i tried to figure out the difference between the implementation as classifier
(link above) and this implementation as an ematch.

Do we have any disadvantages using the ematch? 

The performance of ematch might be slightly lower than of standalone
classifier. Rosta will compare the performance soon. 

E.g. is it still possible to add additional ematches like checking for
patterns inside can_frame.data[] (which is located in skb->data) with
ematch_u32 or e.g. ematch_text ??

AFAIK, this should be possible and it will be a big advantage over
implementation as a standalone classifier.

Regards,
-Michal