Re: API to support hardware priorities

[Oliver Hartkopp <socketcan@hartkopp.net>]

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