Re: [PATCH v2 00/12] can: rx-offload: add implmentation and switch flexcan driver to use it

[Alexander Stein <alexander.stein@systec-electronic.com>]

Hi,

On Monday 04 July 2016 20:32:05, Marc Kleine-Budde wrote:
> this patch takes up the idea to read the CAN frames in IRQ context and send
> them later in NAPI. The first two patches add each an offloading scheme.
> 
> The first one is for hardware FIFO based cores, like the flexcan in FIFO
> mode. The second one requires mailboxes with timestamps. The mailboxes are
> read and sorted by timestamp in IRQ context, sending is done later in NAPI
> aswell.
> 
> The remaining patches modify the flexcan driver to make use of it. imx6 and
> vf610 SoCs can make use of the 64 mailbox software FIFO, while older SoCs
> still use flexcan's 6 mailbox deep hardware FIFO.
> 
> Testing on any flexcan core is highly appreciated.

We did some tests on our custom i.MX35 based board. This means we are stuck at the 6 mailbox deep hardware FIFO.
This is how our test works:
* Send 2 * 250000 CAN frames to the i.MX board, in 2 * 250 burst sizes at 1MBit/s
* Running iperf in parallel

Originally we used 3.10.95-rt102 (RT enabled) and lost CAN frames. The CAN-IRQ-Thread has been prioritized to SCHED_FIFO 91.
Then we updated to 4.6.7-rt13. Without those patches in either case, RT enabled or not, the hardware FIFO still overran.
When this patchset is applied the non-RT configuration successfully received all CAN frames without any drop. Unfortunately when RT is enabled there are still hardware overruns. A first try on the newly released 4.6.7-rt14 improved the situation, there are less overruns, but they still exist.

In summary the non-RT case seems fine now, but I wonder what causes the delays on RT to the CAN-IRQ-Thread which seem to be about 500us (bus time of 6 4Byte CAN frames).

Best regards,
Alexander