All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.