netdev - Re: [very-RFC 0/8] TSN driver for the kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 14 Jun 2016 10:35:55 +0200
From:	Henrik Austad <henrik@...tad.us>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	Richard Cochran <richardcochran@...il.com>,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	alsa-devel@...r.kernel.org, netdev@...r.kernel.org,
	henrik@...tad.us, Arnd Bergmann <arnd@...aro.org>
Subject: Re: [very-RFC 0/8] TSN driver for the kernel

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

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)