Re: at91 driver lost CAN messages

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

On Sunday 12 March 2017 00:06:02, Oliver Hartkopp wrote:
> Hi Efim,
> 
> On 03/10/2017 02:48 PM, Efim Monjak wrote:
> > If napi polling is deactivated by follow change no more receive overflow
> > error occurs.
> 
> thanks for the patch!
> 
> In fact I always thought NAPI is too heavy for CAN controllers. NAPI was
> intended for a very high interrupt load on some ethernet controllers
> with some considerable RX FIFO.
> 
> I have a 20 CAN interfaces (SJA1000 driver) Core i7 system receiving
> ~22.000 frames/s without any problems, with an one-element FIFO and
> without NAPI.
> 
> @Marc: What was the reason to implement NAPI that days? Has it ever been
> proved that NAPI had a remarkable positive effect in opposite to a
> direct CAN frame processing in the interrupt context?

One reason to use NAPI is out-of-order issues on SMP systems :-( You know the 
problem: http://marc.info/?l=linux-can&m=143642135416355&w=2
If this is not resolved, things get even worse.
Well, now that there is generic FIFO-offload feature (drivers may need changes 
to use it) there is an easy way to read CAN frames with low latency while 
processing them in non-IRQ context.
IMHO reading CAN frames in softirq (NAPI) may be too late in some cases, in RT 
kernels this may be even worse.

Best regards,
Alexander
-- 
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein@systec-electronic.com

Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany

Office: +49 (0) 3765 38600-0
Fax:    +49 (0) 3765 38600-4100
 
Managing Directors:
	Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
	Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
	Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010