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:	Sun, 12 Jun 2016 19:43:34 +0900
From:	Takashi Sakamoto <o-takashi@...amocchi.jp>
To:	Henrik Austad <henrik@...tad.us>, alsa-devel@...a-project.org
Cc:	netdev@...r.kernel.org, linux-media@...r.kernel.org
Subject: Re: [very-RFC 0/8] TSN driver for the kernel

On Jun 12 2016 17:31, Henrik Austad wrote:
> 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?

I don't think it's a beter way for you to study USB Audio Device Class
driver unless you're interested in ALSA or USB subsystem.

(But for your information, snd-usb-audio is in sound/usb/* of Linux
kernel. IEC 61883-1/6 driver is in sound/firewire/*.)

We need different strategy to achieve it on different transmission backend.

> Knowing where to start looking is a tremendous help

It's not well-documented, and not well-generalized for packet-oriented
drivers. Most of developers who have enough knowledge about it work for
DMA-oriented drivers in mobile platforms and have little interests in
packet-oriented drivers. You need to find your own way.

Currently I have few advices to you, because I'm also on the way for
drivers to process IEC 61883-1/6 packets on IEEE 1394 bus with enough
accuracy and granularity. The paper I introduced is for the way (but not
mature).

I wish you get more helps from the other developers. Your work is more
significant to Linux system, than mine.

(And I hope your future work get no ignorance and no unreasonable
hostility from coarse users.)


Regards

Takashi Sakamoto



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