linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Sebastian Haas <dev@sebastianhaas.info>
Cc: Kurt Van Dijck <kurt.van.dijck@eia.be>,
	Sandro Anders | CarMediaLab <sandro.anders@carmedialab.de>,
	linux-can Mailing List <linux-can@vger.kernel.org>
Subject: RFC SFF bitfield filter - was Re: RFC: (optional) software filtering in candump
Date: Sun, 02 Jun 2013 11:59:14 +0200	[thread overview]
Message-ID: <51AB1772.2000608@hartkopp.net> (raw)
In-Reply-To: <51AA3ED6.9010806@sebastianhaas.info>


> Am 01.06.2013 16:15, schrieb Oliver Hartkopp:

>> The idea is to introduce a new socket option CAN_RAW_FILTER_UNIQUE for the
>> RAW socket, that catches and omits duplicate frames when it's enabled.
>> This is a per-socket option and is active for all configured filters applied
>> to this socket.
>>
>> It's a relatively small and clear change and it fixes your "bug".
>>
>> Here's the output of candump with and without the 'unique' option when
>> invoking "cansend vcan0 1FF#" in another terminal:
>>
>> $ ./candump vcan0,100~7FF,101~7FF
>>    vcan0  1FF   [0]
>>    vcan0  1FF   [0]
>>
>> $ ./candump vcan0,100~7FF,101~7FF,U
>>    vcan0  1FF   [0]
>>
>> I hope this fit your needs ?! :-)
> Yes it does. It may not be a "clean" solution, but it fixes the issue.
> 

Yes. It is a bit of a fix that handles overlapping filters but is does not
provide a logical AND operation on a bigger number of inverted filters.

E.g. i wanted to remove some single SFF CAN IDs in the 3xx and 5xx range,
which lead to something like this:

candump vcan0,100~C0000100,500:C0000500,333:C00007FF, ...

100~C0000100 -> NOT 1XX 3XX 5XX 7XX SFF frames
500:C0000500 -> add 5XX 7XX again
333:C00007FF, ... -> add single IDs in the 1XX 3XX range

It was a mess. The current filters are not optimized for complex requirements.

Even if it only would be usable for the SFF CAN IDs 0 .. 2048, i wonder if it
would help to configure a 2048 bit bitfield for a 'really individual' filter.

The CAN_RAW socket would get a new sockopt which sets a 128 byte array
(2048/8) to specify for each single CAN ID if it can pass the filter:

u8 bfield[128] /* 2048 bit */

Check at CAN frame reception:

if (can_id & FFFFF800 == 0) { /* no EFF / RTR / ERR and max 0x7FF */

    if ( bfield[can_id >> 3] & 1 << (can_id & 7) ) {

        /* can_id matched */

    }
}

What is your opinion?

Does this kind of individual bitfield filter help for your use-cases?

Regards,
Oliver



  reply	other threads:[~2013-06-02  9:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-29 20:55 RxFilter issues vcan Sebastian Haas
2013-05-30  4:58 ` Oliver Hartkopp
2013-05-30  8:34   ` Sebastian Haas
2013-05-30  8:49     ` Oliver Hartkopp
2013-05-30  9:06       ` Sebastian Haas
2013-05-30 10:17         ` RFC: (optional) software filtering in candump Kurt Van Dijck
2013-05-30 12:07           ` Oliver Hartkopp
2013-05-30 12:35             ` Kurt Van Dijck
2013-05-30 15:37               ` Sebastian Haas
2013-05-30 15:55                 ` Oliver Hartkopp
2013-05-31 20:40                   ` Sebastian Haas
2013-06-01 14:15                 ` Oliver Hartkopp
2013-06-01 18:35                   ` Sebastian Haas
2013-06-02  9:59                     ` Oliver Hartkopp [this message]
2013-06-02 11:17                       ` RFC SFF bitfield filter - was " Kurt Van Dijck
2013-06-02 12:23                         ` Sebastian Haas
2013-06-02 11:23                   ` Kurt Van Dijck
2013-06-04  8:22                     ` AW: " Sandro Anders | CarMedialab
2015-03-17 10:44                   ` Marc Kleine-Budde
2015-03-17 11:34                   ` Marc Kleine-Budde
2015-03-17 12:04                     ` Oliver Hartkopp
2015-03-17 13:02                       ` Oliver Hartkopp
2015-03-17 13:33                         ` Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51AB1772.2000608@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=dev@sebastianhaas.info \
    --cc=kurt.van.dijck@eia.be \
    --cc=linux-can@vger.kernel.org \
    --cc=sandro.anders@carmedialab.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).