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

[Oliver Hartkopp <socketcan@hartkopp.net>]

Hi Stephane,

On 29.06.2015 18:13, Oliver Hartkopp wrote:
> Hi Stephane,
>
> On 25.06.2015 11:36, Oliver Hartkopp wrote:
>>> Stephane Grosjean <s.grosjean@peak-system.com>
>>> (..)
>>> tells that he's facing some loss of frames with the PEAK-System PCAN-USB
>>> adapter, in case of "relatively"  high bus load... He's running two
>>> Kernels (3.19 and the last 4.1 patched with this recent "fix"). At the
>>> moment, he says he always notes some frame leakage, especially when he
>>> (for example) "resizes windows on his desktop"...

Is $COSTUMERs problem fixed now?

While testing the patches

can: fix loss of CAN frames in raw_rcv
http://git.kernel.org/cgit/linux/kernel/git/mkl/linux-can.git/commit/?h=testing&id=36c01245eb8046c16eee6431e7dbfbb302635fa8

and

can: replace timestamp as unique skb attribute
http://git.kernel.org/cgit/linux/kernel/git/mkl/linux-can.git/commit/?h=testing&id=a6ffebda241e513f6e839662d769b60b084d0957

I discovered an increase of out-of-order CAN frame receptions.
My setup is a core i7 with a PCAN USB and a PCAN USB pro connected to my full 
busload CAN source (1MBit/s, ~8008 frames/s).

With 3.16 the out-of-order CAN frame reception is 'relatively' seldom.
It's more with the PCAN USB and very few with PCAN USB pro.

With the latest 4.2-merge the effect is reproducible after some time (~10min).

Examples:

  drop detected: expected 204 received 212
  drop detected: expected 237 received 204
  drop detected: expected 212 received 237
  drop detected: expected 68 received 69
  drop detected: expected 70 received 68
  drop detected: expected 69 received 70

Obviously the frames do not get lost BUT are reordered.

newcounter = frame.data[0];
if (((counter + 1) & 0xFF) != newcounter) {
  printf(" drop detected: expected %u received %u\n", counter + 1, newcounter);
}
counter = newcounter;

I'm a bit confused as this effect seems to increase with Linux kernel version 
numbers. I removed all the changes for 4.1 in the 4.2-merge kernel to have a 
4.0 CAN subsystem (which was stable for a long time) - but even this patch 
removal did not fix the out of order reception.

Good thing: The latest changes in 4.1 (which patches) do not drop CAN frames 
by accident.

Bad thing: Why is the out-of-order reception increasing in Linux?

I /assume/ some changes with RPS (receive packet steering) in the network 
layer ...


Regards,
Oliver