linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Benedikt Spranger <b.spranger@linutronix.de>,
	Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Wolfgang Grandegger <wg@grandegger.com>,
	linux-can <linux-can@vger.kernel.org>
Subject: Re: API to support hardware priorities
Date: Mon, 9 Nov 2015 14:51:32 +0100	[thread overview]
Message-ID: <5640A4E4.6020005@pengutronix.de> (raw)
In-Reply-To: <5640A065.2000401@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]

On 11/09/2015 02:32 PM, Marc Kleine-Budde wrote:
> Let's move this discussion to the mailing list. I'll translate your
> questions.
> 
> On 11/09/2015 12:36 PM, Benedikt Spranger wrote:
>> C-CAN und D-CAN basierte Hardware (wie auch andere) unterstützt ja das
>> priorisierende Versenden von CAN-Paketen. Gibt es Bestrebungen, dieses
>> Feature in der API abzubilden?
> 
> Several CAN IP cores support prioritisation of CAN frames. Is it planned
> to support this?

There are two buffers before a CAN frame gets send to the wire:
First there is the queueing in the network layer. You can replace the
FIFO of the interface by a multi prio queue and filter your CAN frames
by CAN-ID.

The second buffer might be the in the hardware. For now each driver
ensures that the buffer in configured as a FIFO. Some CAN IP cores
support sending CAN frames based on the CAN-ID (lowest ID first), some
have a priority value, some cores even combine these two.

Several thoughts on this:

IIRC the kernel networking driver API supports several TX queues per
networking device. We might be exploited this to implement a bulk large
FIFO queue and a high prio no just one buffer TX queue per driver.

We can introduce a per device knob to switch a CAN driver from true TX
FIFO mode to CAN-ID based priority TX mode. The driver's TX and
TX-complete routines have to be adopted as they now assume that the CAN
frames are send in true FIFO order. The feature can be toggled via
netlink/canconfig.

>> Im konkreten Fall werden neben Bulk-Daten azyklisch auch zeitkritische
>> CAN-Pakete versendet. Hierbei ist eine FIFO-Abarbeitung störend. Das
>> Mailbox-basierte Design von C-CAN/D-CAN unterstützt ja neben der
>> Verwendung der Mailboxen als FIFO auch die dedizierte Konfiguration auf
>> eine CAN-Id/Maske.
> 
> Bene want to send bulk data and time critical cyclic data. Using a
> hardware FIFO introduces unwanted latencies. He further mentions that
> it's possible to configure the mailboxes to serve a CAN-ID/mask.

Are we talking about RX or TX here?

Do you mean the mailbox feature, where you queue a frame into hardware,
but sending is delayed until a certain CAN-ID is RX'ed?

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  reply	other threads:[~2015-11-09 13:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20151109123618.41ad1bae@mitra>
2015-11-09 13:32 ` API to support hardware priorities (was: Re: API zur hardwareunterstützten Priorisierung von CAN-Paketen) Marc Kleine-Budde
2015-11-09 13:51   ` Marc Kleine-Budde [this message]
2015-11-09 14:04     ` API to support hardware priorities Oliver Hartkopp
2015-11-09 15:27     ` Benedikt Spranger
2015-11-09 15:38       ` Marc Kleine-Budde
2015-11-09 16:36         ` Benedikt Spranger

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=5640A4E4.6020005@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=b.spranger@linutronix.de \
    --cc=linux-can@vger.kernel.org \
    --cc=socketcan@hartkopp.net \
    --cc=wg@grandegger.com \
    /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;
as well as URLs for NNTP newsgroup(s).