Oliver Hartkopp wrote:
> Subhasish Ghosh wrote:
>
>> The CAN controller that I am using allows configuring per-mailbox IDs.
>> CAN being a broadcast network, this feature reduces the interrupts to
>> the processor.
>>
>> From Documentation/can.txt, what I understand is that the socketcan
>> interface does not provide any mechanism to configure the h/w for this
>> purpose (chapter 6.3).
>>
>> Instead, the h/w is configured to receive all identifiers and the
>> filtering is done on the stack (like ti_hecc.c) and to avoid hogging the
>> processor some interrupt mitigation techniques like NAPI is implemented.
>>
>> Isn't this a work around?
>
>
> No it's not.
>
> Remember that you're working in a multi-user system now, and therefore it's
> not defined what all of your user-apps need from the specific CAN bus.
>
> For that reason the implementation of efficient filters is done in the
> soft-IRQ that's called right after the (hard-) interrupt routine of the CAN
> driver.
>
> Having a generic CAN driver interface is one of the major motivations for
> SocketCAN. You really don't want to have hardware-specific ("N mailboxes")
> configuration interfaces which leads into a maintenance hell.
Yes, I also do not see a generic way yet to support per mailbox (or
message object) filtering.
>> My question is, did I miss something, is there any way to configure the
>> h/w for this purpose. Is it a good idea if I cook up a sysfs interface
>> for my driver for this.
>
>
> The problem is, that a filtering on driver level affects *every* user in the
> system.
Yes, messages rejected by hardware filters are lost.
> So far no one discovered a problem with the irq-load of CAN drivers in his
> system. We've been running a 133MHz PowerPC with four SJA1000 controllers for
> years ...
Interrupt load might be an issue, especially on load end systems.
> If you really(!) get into problems, we should discuss a netlink configuration
> option for driver-level CAN-ID filtering (also abstracted from "mailboxes").
Yes.
> But please check if it's really needed and if you probably have a different
> view on the general approach of SocketCAN now.
Some kind of generic hardware filter support might be useful for some
corner cases, I think. Does anyone else find it useful?
Wolfgang.
_______________________________________________
Socketcan-users mailing list
Socketcan-users@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/socketcan-users
