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]

Message-ID: <20160612083122.GB32724@icarus.home.austad.us>
Date:	Sun, 12 Jun 2016 10:31:22 +0200
From:	Henrik Austad <henrik@...tad.us>
To:	Takashi Sakamoto <o-takashi@...amocchi.jp>
Cc:	alsa-devel@...a-project.org, netdev@...r.kernel.org,
	linux-media@...r.kernel.org, alsa-devel@...r.kernel.org,
	henrk@...tad.us
Subject: Re: [very-RFC 0/8] TSN driver for the kernel

On Sun, Jun 12, 2016 at 01:30:24PM +0900, Takashi Sakamoto wrote:
> On Jun 12 2016 12:38, Takashi Sakamoto wrote:
> > In your patcset, there's no actual codes about how to handle any
> > interrupt contexts (software / hardware), how to handle packet payload,
> > and so on. Especially, for recent sound subsystem, the timing of
> > generating interrupts and which context does what works are important to
> > reduce playback/capture latency and power consumption.
> > 
> > Of source, your intention of this patchset is to show your early concept
> > of TSN feature. Nevertheless, both of explaination and codes are
> > important to the other developers who have little knowledges about TSN,
> > AVB and AES-64 such as me.
> 
> Oops. Your 5th patch was skipped by alsa-project.org. I guess that size
> of the patch is too large to the list service. I can see it:
> http://marc.info/?l=linux-netdev&m=146568672728661&w=2
> 
> As long as seeing the patch, packets are queueing in hrtimer callbacks
> every 1 seconds.

Actually, the hrtimer fires every 1ms, and that part is something I have to 
do something about, also because it sends of the same number of frames 
every time, regardless of how accurate the internal timer is to the rest of 
the network (there's no backpressure from the networking layer).

> (This is a high level discussion and it's OK to ignore it for the
> moment. When writing packet-oriented drivers for sound subsystem, you
> need to pay special attention to accuracy of the number of PCM frames
> transferred currently, and granularity of the number of PCM frames
> transferred by one operation. In this case, snd_avb_hw,
> snd_avb_pcm_pointer(), tsn_buffer_write_net() and tsn_buffer_read_net()
> are involved in this discussion. You can see ALSA developers' struggle
> in USB audio device class drivers and (of cource) IEC 61883-1/6 drivers.)

Ah, good point. Any particular parts of the USB-subsystem I should start 
looking at? Knowing where to start looking is a tremendous help

Thanks for the feedback!

-- 
Henrik Austad

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