From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Jander Subject: Re: [PATCH v2 00/12] can: rx-offload: add implmentation and switch flexcan driver to use it Date: Tue, 4 Oct 2016 14:33:15 +0200 Message-ID: <20161004143315.23423e56@erd980> References: <1467657137-18891-1-git-send-email-mkl@pengutronix.de> <12311540.OPjVtcIYq6@ws-stein> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from protonic.xs4all.nl ([83.163.252.89]:6452 "EHLO protonic.xs4all.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753471AbcJDMdR (ORCPT ); Tue, 4 Oct 2016 08:33:17 -0400 In-Reply-To: <12311540.OPjVtcIYq6@ws-stein> Sender: linux-can-owner@vger.kernel.org List-ID: To: Alexander Stein Cc: Marc Kleine-Budde , linux-can@vger.kernel.org, Martin =?ISO-8859-1?Q?D=E4umler?= , Daniel =?ISO-8859-1?Q?Kr=FCger?= On Tue, 04 Oct 2016 13:57:33 +0200 Alexander Stein wrote: > Hi, > > On Monday 04 July 2016 20:32:05, Marc Kleine-Budde wrote: > > this patch takes up the idea to read the CAN frames in IRQ context and send > > them later in NAPI. The first two patches add each an offloading scheme. > > > > The first one is for hardware FIFO based cores, like the flexcan in FIFO > > mode. The second one requires mailboxes with timestamps. The mailboxes are > > read and sorted by timestamp in IRQ context, sending is done later in NAPI > > aswell. > > > > The remaining patches modify the flexcan driver to make use of it. imx6 and > > vf610 SoCs can make use of the 64 mailbox software FIFO, while older SoCs > > still use flexcan's 6 mailbox deep hardware FIFO. > > > > Testing on any flexcan core is highly appreciated. > > We did some tests on our custom i.MX35 based board. This means we are stuck > at the 6 mailbox deep hardware FIFO. This is how our test works: > * Send 2 * 250000 CAN frames to the i.MX board, in 2 * 250 burst sizes at > 1MBit/s > * Running iperf in parallel > > Originally we used 3.10.95-rt102 (RT enabled) and lost CAN frames. The > CAN-IRQ-Thread has been prioritized to SCHED_FIFO 91. Then we updated to > 4.6.7-rt13. Without those patches in either case, RT enabled or not, the > hardware FIFO still overran. When this patchset is applied the non-RT > configuration successfully received all CAN frames without any drop. > Unfortunately when RT is enabled there are still hardware overruns. A first > try on the newly released 4.6.7-rt14 improved the situation, there are less > overruns, but they still exist. > > In summary the non-RT case seems fine now, but I wonder what causes the > delays on RT to the CAN-IRQ-Thread which seem to be about 500us (bus time of > 6 4Byte CAN frames). Thanks for testing! Well, in -RT I guess anything with a higher priority than the CAN-IRQ can cause a delay... but since going from -rt13 to -rt14 improved the situation, this sounds like bugs in the -rt code. Are you running any code in SCHED_FIFO that you don't run in the non-RT case? It's nevertheless very nice to see that for non-RT, you got from losing messages to not losing any message with this patchset, even on a lowly i.MX35 at 1Mbit/s! This proves that the patchset is certainly worth it. Best regards, -- David Jander Protonic Holland.