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 > > > > 1. A proper userland stack for AVDECC, MAAP, FQTSS, and so on. The > > OpenAVB project does not offer much beyond simple examples. > > > > 2. 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 > > > > 1. 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.) > > > > 2. 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! -- Henrik Austad
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
