Linux CAN drivers development
 help / color / mirror / Atom feed
From: Alexander Stein <alexander.stein@systec-electronic.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>,
	Efim Monjak <emonjak@lipowsky.de>,
	linux-can@vger.kernel.org
Subject: Re: at91 driver lost CAN messages
Date: Thu, 16 Mar 2017 10:06:37 +0100	[thread overview]
Message-ID: <3117407.TP9DfUe48K@ws-stein> (raw)
In-Reply-To: <1666b5da-6ed9-a6f4-214a-d33bc0ab4aaa@pengutronix.de>

On Thursday 16 March 2017 09:34:38, Marc Kleine-Budde wrote:
> On 03/16/2017 09:01 AM, Oliver Hartkopp wrote:
> > On 13.03.2017 10:47, Marc Kleine-Budde wrote:
> >> On 03/13/2017 07:54 AM, Alexander Stein wrote:
> >>>> @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.
> >> 
> >> ACK.
> > 
> > Would then implementing CAN rx-offload on all(!) CAN drivers fix the
> > NAPI-too-late and the out-of-order issue?
> 
> Implementing rx-offload on the drivers using NAPI, will fix the
> NAPI-too-late issue (and turn it into a IRQ too late issue).
> 
> Implementing rx-offload on the drivers passing skbs in the IRQ handler
> will probably fix the out-of-order issue.
> 
> I'm not sure if the USB and SPI drivers are affected by the out-of-order
> issue.

IMO all drivers using netif_rx (IRQ context) rather han netif_receive_skb 
(NAPI poll context) are suffering from out-of-order issue. And I guess every 
USB CAN driver is using netif_rx in the URB callback function, which is 
essentially IRQ context. MCP2512 uses netif_rx_ni instead, dunno what is the 
actual difference to netif_rx.

Let's see if I get time to cook rx-offload on a USB driver.

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


  reply	other threads:[~2017-03-16  9:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-10 13:48 at91 driver lost CAN messages Efim Monjak
2017-03-11 23:06 ` Oliver Hartkopp
2017-03-13  6:54   ` Alexander Stein
2017-03-13  9:47     ` Marc Kleine-Budde
2017-03-16  8:01       ` Oliver Hartkopp
2017-03-16  8:34         ` Marc Kleine-Budde
2017-03-16  9:06           ` Alexander Stein [this message]
2017-03-16  9:09             ` Oliver Hartkopp
2017-03-16  9:58               ` Alexander Stein
2017-03-16 10:18                 ` Marc Kleine-Budde
2017-03-20  7:38                   ` Alexander Stein
2017-03-16  9:07           ` Oliver Hartkopp
2017-03-16  9:24           ` Efim Monjak
2017-03-16  9:32             ` Marc Kleine-Budde
2017-03-16 10:06               ` Efim Monjak
2017-03-16 10:11                 ` Marc Kleine-Budde
2017-03-13  9:47   ` Marc Kleine-Budde
2017-03-13 12:55     ` Efim Monjak
2017-03-13 13:11       ` Marc Kleine-Budde
2017-03-13 15:17         ` Efim Monjak
2017-03-13 14:23           ` Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3117407.TP9DfUe48K@ws-stein \
    --to=alexander.stein@systec-electronic.com \
    --cc=emonjak@lipowsky.de \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=socketcan@hartkopp.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox