On Mon, Jun 13, 2016 at 08:56:44AM -0700, John Fastabend wrote:
On 16-06-13 04:47 AM, Richard Cochran wrote:
[...] Here is what is missing to support audio TSN:
- User Space
A proper userland stack for AVDECC, MAAP, FQTSS, and so on. The OpenAVB project does not offer much beyond simple examples.
A user space audio application that puts it all together, making use of the services in #1, the linuxptp gPTP service, the ALSA services, and the network connections. This program will have all the knowledge about packet formats, AV encodings, and the local HW capabilities. This program cannot yet be written, as we still need some kernel work in the audio and networking subsystems.
- Kernel Space
Providing frames with a future transmit time. For normal sockets, this can be in the CMESG data. For mmap'ed buffers, we will need a new format. (I think Arnd is working on a new layout.)
Time based qdisc for transmitted frames. For MACs that support this (like the i210), we only have to place the frame into the correct queue. For normal HW, we want to be able to reserve a time window in which non-TSN frames are blocked. This is some work, but in the end it should be a generic solution that not only works "perfectly" with TSN HW but also provides best effort service using any NIC.
When I looked at this awhile ago I convinced myself that it could fit fairly well into the DCB stack (DCB is also part of 802.1Q). A lot of the traffic class to queue mappings and priories could be handled here. It might be worth taking a look at ./net/sched/mqprio.c and ./net/dcb/.
Interesting, I'll have a look at dcb and mqprio, I'm not familiar with those systems. Thanks for pointing those out!
I hope that the complexity doesn't run crazy though, TSN is not aimed at datacentra, a lot of the endpoints are going to be embedded devices, introducing a massive stack for handling every eventuality in 802.1q is going to be counter productive.
Unfortunately I didn't get too far along but we probably don't want another mechanism to map hw queues/tcs/etc if the existing interfaces work or can be extended to support this.
Sure, I get that, as long as the complexity for setting up a link doesn't go through the roof :)
Thanks!