* API to support hardware priorities (was: Re: API zur hardwareunterstützten Priorisierung von CAN-Paketen)
[not found] <20151109123618.41ad1bae@mitra>
@ 2015-11-09 13:32 ` Marc Kleine-Budde
2015-11-09 13:51 ` API to support hardware priorities Marc Kleine-Budde
0 siblings, 1 reply; 6+ messages in thread
From: Marc Kleine-Budde @ 2015-11-09 13:32 UTC (permalink / raw)
To: Benedikt Spranger, Oliver Hartkopp; +Cc: Wolfgang Grandegger, linux-can
[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]
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?
> 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.
Hope I've got the gist of your mail, correct me if needed. :)
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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: API to support hardware priorities
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
2015-11-09 14:04 ` Oliver Hartkopp
2015-11-09 15:27 ` Benedikt Spranger
0 siblings, 2 replies; 6+ messages in thread
From: Marc Kleine-Budde @ 2015-11-09 13:51 UTC (permalink / raw)
To: Benedikt Spranger, Oliver Hartkopp; +Cc: Wolfgang Grandegger, linux-can
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: API to support hardware priorities
2015-11-09 13:51 ` API to support hardware priorities Marc Kleine-Budde
@ 2015-11-09 14:04 ` Oliver Hartkopp
2015-11-09 15:27 ` Benedikt Spranger
1 sibling, 0 replies; 6+ messages in thread
From: Oliver Hartkopp @ 2015-11-09 14:04 UTC (permalink / raw)
To: Benedikt Spranger, Marc Kleine-Budde; +Cc: linux-can, Wolfgang Grandegger
Hopefully the webmailer doesn't kill the formatting ... but it seems to be
urgent :-)
We have an ematch implementation for CAN:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/sched/em_canid.c
See idea here:
http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf
The idea is still to have a very short TX FIFO in the driver and fix the
'multi-user' issues in the TX part of the queueing-disciplines.
Regards,
Oliver
> Marc Kleine-Budde <mkl@pengutronix.de> hat am 9. November 2015 um 14:51
> geschrieben:
>
>
> 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 |
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: API to support hardware priorities
2015-11-09 13:51 ` API to support hardware priorities Marc Kleine-Budde
2015-11-09 14:04 ` Oliver Hartkopp
@ 2015-11-09 15:27 ` Benedikt Spranger
2015-11-09 15:38 ` Marc Kleine-Budde
1 sibling, 1 reply; 6+ messages in thread
From: Benedikt Spranger @ 2015-11-09 15:27 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: Oliver Hartkopp, Wolfgang Grandegger, linux-can
On Mon, 9 Nov 2015 14:51:32 +0100
Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> Are we talking about RX or TX here?
TX.
> 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?
No.
The C-CAN/D-CAN and some other Controller can be configured to have
mailboxes for a certain Id. For example you can configure MBX 1 for
Id 23, MBX 2 for Id 42 and 3-7 act as FIFO. So every packet matching Id
23 should queued up to MBX 1, every package matching Id 42 to MBX 2 and
all other Packages to the FIFO.
Having a multiqueue TX part may help but may have some drawbacks. If the
FIFO (or an other queue) is full the driver calls netif_stop_queue().
Sending bulk data can block out a "high priority" Package. On the other
hand a application writing bulk data in blocking mode should not
receive a EAGAIN and not be punished by a "mixed up" queue i.e.
violating the package send order.
Regards
Bene
--
Linutronix GmbH
Phone: +49 7556 4521 890; Fax.: +49 7556 91 98 86
Firmensitz: D-88690 Uhldingen, Auf dem Berg 3
Registergericht: Freiburg i. Br., HRB 700 806;
Geschäftsführer: Heinz Egger, Thomas Gleixner
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: API to support hardware priorities
2015-11-09 15:27 ` Benedikt Spranger
@ 2015-11-09 15:38 ` Marc Kleine-Budde
2015-11-09 16:36 ` Benedikt Spranger
0 siblings, 1 reply; 6+ messages in thread
From: Marc Kleine-Budde @ 2015-11-09 15:38 UTC (permalink / raw)
To: Benedikt Spranger; +Cc: Oliver Hartkopp, Wolfgang Grandegger, linux-can
[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]
On 11/09/2015 04:27 PM, Benedikt Spranger wrote:
>> 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?
> No.
> The C-CAN/D-CAN and some other Controller can be configured to have
> mailboxes for a certain Id. For example you can configure MBX 1 for
> Id 23, MBX 2 for Id 42 and 3-7 act as FIFO. So every packet matching Id
> 23 should queued up to MBX 1, every package matching Id 42 to MBX 2 and
> all other Packages to the FIFO.
OK, I was not aware of that feature. I'll have a look to the datasheets.
What's the benefit of associating a mailbox to a specific ID in the
hardware?
> Having a multiqueue TX part may help but may have some drawbacks. If the
> FIFO (or an other queue) is full the driver calls netif_stop_queue().
In this scenario there will be two netif_queues per CAN driver....
> Sending bulk data can block out a "high priority" Package. On the other
> hand a application writing bulk data in blocking mode should not
> receive a EAGAIN and not be punished by a "mixed up" queue i.e.
> violating the package send order.
...one serving the bulk hardware FIFO and one serving the high prio HW
queue.
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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: API to support hardware priorities
2015-11-09 15:38 ` Marc Kleine-Budde
@ 2015-11-09 16:36 ` Benedikt Spranger
0 siblings, 0 replies; 6+ messages in thread
From: Benedikt Spranger @ 2015-11-09 16:36 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: Oliver Hartkopp, Wolfgang Grandegger, linux-can
Am Mon, 9 Nov 2015 16:38:09 +0100
schrieb Marc Kleine-Budde <mkl@pengutronix.de>:
> OK, I was not aware of that feature. I'll have a look to the
> datasheets. What's the benefit of associating a mailbox to a specific
> ID in the hardware?
A "stop all engines. NOW!"-message would not blocked by 1001 bulk
messages telling about air pressure, temperature and sunshine.
Look at it from a "classic" microcontroller POV.
> ...one serving the bulk hardware FIFO and one serving the high prio HW
"tree/net/sched/em_canid.c" and multiple queues look promising.
Will have a deeper look at it.
Regards
Bene
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-11-09 16:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[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 ` API to support hardware priorities Marc Kleine-Budde
2015-11-09 14:04 ` Oliver Hartkopp
2015-11-09 15:27 ` Benedikt Spranger
2015-11-09 15:38 ` Marc Kleine-Budde
2015-11-09 16:36 ` Benedikt Spranger
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.