Re: Flexcan (was: Re: Fwd: Querying current tx_queue usage of a SocketCAN interface)

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

On 2/04/2015 10:35 PM, Tom Evans wrote:
> On 2/04/2015 5:28 PM, Marc Kleine-Budde wrote:
>> On 04/02/2015 04:20 AM, Tom Evans wrote:
>>> I had to seriously rewrite the FlexCAN drivers for our
 >>> i.MX53 because the Ethernet driver blocked the CAN
 >>> driver for so long the CAN hardware receive FIFO overflowed.
 >>
>> Can you share your changes? I'll have some days to hack on a better
>> generic RX-FIFO implementation for the at91 and flexcan.
>
> Sure. "git diff -p" based of the 3.4 kernel sources.

> flexcan.c.patch.buffer
>
> So I fixed it with a sledgehammer. It reads the messages
 > during the ISR to an internal ring buffer (sized to 100,
 > later to 128)

And schedules NAPI to forward them from there rather than reading them 
from the hardware FIFO.

The purpose of NAPI is to make the interrupts as fast as possible, doing 
as little work as possible, but servicing time-critical hardware so it 
doesn't overflow/underflow. Operations like reading characters from a 
serial port.

But that assumes the "little work" is fast. In the case of the FlexCAN 
driver, it takes about 5 reads and a write to read a CAN message, and 
there may be six messages in the FIFO.

Not many accesses, but peripheral device registers can be notoriously 
slow on some CPUs [1]. I've worked on an ARM-based PXA CPU that took 
something like 200 CPU clocks to read a GPIO port once. I don't know how 
fast or slow the FlexCAN register reads and writes are on the i.MX53. If 
they're too slow then my patches may be increasing interrupt latency for 
a given value of "too much".

I'll try and measure this on Tuesday.

Tom