From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rostislav Lisovy Subject: Re: [RFC] net/sched/em_canid: Ematch rule to match CAN frames according to their CAN IDs Date: Tue, 12 Jun 2012 16:50:22 +0200 Message-ID: <1339512622.8536.3.camel@lolumad> References: <1339508913-7784-1-git-send-email-lisovy@gmail.com> <1339509809.22704.149.camel@edumazet-glaptop> <1339511593.22704.157.camel@edumazet-glaptop> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, linux-can@vger.kernel.org, lartc@vger.kernel.org, pisa@cmp.felk.cvut.cz, sojkam1@fel.cvut.cz To: Eric Dumazet Return-path: Received: from mail-yw0-f46.google.com ([209.85.213.46]:63808 "EHLO mail-yw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753174Ab2FLOu1 (ORCPT ); Tue, 12 Jun 2012 10:50:27 -0400 In-Reply-To: <1339511593.22704.157.camel@edumazet-glaptop> Sender: netdev-owner@vger.kernel.org List-ID: On Tue, 2012-06-12 at 16:33 +0200, Eric Dumazet wrote: > On Tue, 2012-06-12 at 16:03 +0200, Eric Dumazet wrote: > > On Tue, 2012-06-12 at 15:48 +0200, Rostislav Lisovy wrote: > > > 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. > > > > > > Signed-off-by: Rostislav Lisovy > > > --- > > > include/linux/can.h | 3 + > > > include/linux/pkt_cls.h | 5 +- > > > net/sched/Kconfig | 10 +++ > > > net/sched/Makefile | 1 + > > > net/sched/em_canid.c | 217 +++++++++++++++++++++++++++++++++++++++++++++++ > > > 5 files changed, 234 insertions(+), 2 deletions(-) > > > create mode 100644 net/sched/em_canid.c > > > > > > diff --git a/include/linux/can.h b/include/linux/can.h > > > index 9a19bcb..08d1610 100644 > > > --- a/include/linux/can.h > > > +++ b/include/linux/can.h > > > @@ -38,6 +38,9 @@ > > > */ > > > typedef __u32 canid_t; > > > > > > +#define CAN_SFF_ID_BITS 11 > > > +#define CAN_EFF_ID_BITS 29 > > > + > > > > > +struct canid_match { > > > + struct can_filter rules_raw[EM_CAN_RULES_SIZE]; /* Raw rules copied > > > + from netlink message; Used for sending information to > > > + userspace (when 'tc filter show' is invoked) AND when > > > + matching EFF frames*/ > > > + DECLARE_BITMAP(match_sff, (1 << CAN_SFF_ID_BITS)); /* For each SFF CAN > > > + ID (11 bit) there is one record in this bitfield */ > > > + int rules_count; > > > + int eff_rules_count; > > > + int sff_rules_count; > > > + > > > + struct rcu_head rcu; > > > +}; > > > > The size of kmalloc() blob to hold this structure is 4 Mbytes > > > > This is a huge cost, and unlikely to succeed but shortly after boot... > > > > (this happens to be the largest possible kmalloc() allocation by the way > > on x86) > > > > > > Oh well, I mixed CAN_SFF_ID_BITS / CAN_EFF_ID_BITS > > Indeed; On x86_64 the sizeof(struct canid_match) is 544 bytes; Regards; Rostislav Lisovy