- To: Michal Sojka <sojkam1@xxxxxxxxxxx>
- Subject: Re: [RFC] net/sched/em_canid: Ematch rule to match CAN frames according to their CAN IDs
- From: Thomas Graf <tgraf@xxxxxxx>
- Date: Wed, 13 Jun 2012 08:18:28 -0400
- Cc: Oliver Hartkopp <socketcan@xxxxxxxxxxxx>, Rostislav Lisovy <lisovy@xxxxxxxxx>, Eric Dumazet <eric.dumazet@xxxxxxxxx>, netdev@xxxxxxxxxxxxxxx, linux-can@xxxxxxxxxxxxxxx, lartc@xxxxxxxxxxxxxxx, pisa@xxxxxxxxxxxxxxxx
- In-reply-to: <878vfr7d4l.fsf@steelpick.2x.cz>
- Mail-followup-to: Michal Sojka <sojkam1@xxxxxxxxxxx>, Oliver Hartkopp <socketcan@xxxxxxxxxxxx>, Rostislav Lisovy <lisovy@xxxxxxxxx>, Eric Dumazet <eric.dumazet@xxxxxxxxx>, netdev@xxxxxxxxxxxxxxx, linux-can@xxxxxxxxxxxxxxx, lartc@xxxxxxxxxxxxxxx, pisa@xxxxxxxxxxxxxxxx
- User-agent: Mutt/1.5.20 (2009-08-17)
On Wed, Jun 13, 2012 at 11:52:10AM +0200, Michal Sojka wrote:
> The performance of ematch might be slightly lower than of standalone
> classifier. Rosta will compare the performance soon.
I think it doesn't make a difference, there is no additional locking
involved. Numbers definitely welcome though.
> > 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.
Definitely and the real advantage is that you can combine these
using logic operators.
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bugtraq]
[Fedora Legacy]
[GCC Help]
[Yosemite News]
[Yosemite Photos]
[IP Tables]
[Netfilter Devel]
[Fedora Users]