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
next prev parent 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