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

[David Jander <david@protonic.nl>]

On Tue, 04 Oct 2016 13:57:33 +0200
Alexander Stein <alexander.stein@systec-electronic.com> wrote:

> 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).

Thanks for testing!
Well, in -RT I guess anything with a higher priority than the CAN-IRQ can
cause a delay... but since going from -rt13 to -rt14 improved the situation,
this sounds like bugs in the -rt code. Are you running any code in SCHED_FIFO
that you don't run in the non-RT case?
It's nevertheless very nice to see that for non-RT, you got from losing
messages to not losing any message with this patchset, even on a lowly i.MX35
at 1Mbit/s! This proves that the patchset is certainly worth it.

Best regards,

-- 
David Jander
Protonic Holland.