API to support hardware priorities (was: Re: API zur hardwareunterstützten Priorisierung von CAN-Paketen)

API to support hardware priorities (was: Re: API zur hardwareunterstützten Priorisierung von CAN-Paketen)

[Marc Kleine-Budde]

[-- 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 --]

Re: API to support hardware priorities

[Marc Kleine-Budde]

[-- 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 --]

Re: API to support hardware priorities

[Oliver Hartkopp]

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   |
>

Re: API to support hardware priorities

[Benedikt Spranger]

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

Re: API to support hardware priorities

[Marc Kleine-Budde]

[-- 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 --]

Re: API to support hardware priorities

[Benedikt Spranger]

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