Re: [BULK]Re: [PATCH] can: fix loss of frames due to wrong assumption in raw_rcv

[Tom Evans <tom_usenet@optusnet.com.au>]

On 06/07/15 15:44, Oliver Hartkopp wrote:
> /me again
>
> On 05.07.2015 20:21, Oliver Hartkopp wrote:
>
>> With
>>
>> # echo 1 > /proc/irq/28/smp_affinity
>> ..
>> and all the out-of-order receptions were totally gone! \o/
>>
>
> I ran the test for 11 hours now (3 x 8000 = 24.000 frames/s).
>
> No single out-of-order frame this time - not even with the PCAN-USB.

I don't think you can force a specific "CPU Affinity Requirement" on this driver.

CPU Affinity may fix this problem, but I suspect there should be a more 
"standard" fix. This sort of problem (multiple CPUs fielding interrupts and 
getting them out of order) should show up elsewhere. It might even swap bytes 
from a UART.

There must be a "standard synchronization technique" of some sort that 
provides the proper sequencing here. Can anyone else reading this thread who 
knows if this is right please chime in?

Google finds:

http://www.alexonlinux.com/why-interrupt-affinity-with-multiple-cores-is-not-such-a-good-thing

     Moreover, assuming TCP connection object is properly
     protected using synchronization techniques, one of
     the cores will inevitably have to wait for the other,
     adding unnecessary delay to packet processing.

It seems to me that the "CAN connection object" is not "properly protected" in 
the existing driver. That CAN driver may not have had the "SMP Magic Wand" 
waved over it.

Tom