Re: [RFC - AAF PCM plugin 3/5] aaf: Implement Playback mode support

["Guedes, Andre" <andre.guedes@intel.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3204 bytes --]

Hi Takashi,

On Mon, 2018-09-03 at 10:24 +0900, Takashi Sakamoto wrote:
> Hi,
> 
> On Sep 1 2018 08:18, Guedes, Andre wrote:
> > > I have another concern of buffering in a perspectives of delay of
> > > task
> > > scheduling.
> > > 
> > > The interval of task scheduling for this plugin is decided mainly
> > > by
> > > the value of 'frames_per_pkt', given by users. In your
> > > documentation,
> > > the value is 6[1]. Of cource this is an example but in this case
> > > the
> > > interval is calculated as 125us at 48.0kHz. In my opinion, task
> > > scheduling in Linux kernel brings deadline misses for the
> > > interval,
> > > in most cases such as major Linux distribution on usual personal
> > > computers. When considering about the fact that recent
> > > motherboards
> > > implements Intel I210/220 series, it's better to care for the
> > > low-
> > > level
> > > realtime systems, in my opinion.
> > 
> > Agreed.
> > 
> > To mitigate this scheduling issue, a follow-up patchset will extend
> > the
> > plugin to leverage the ETF qdisc [1] which will be available on
> > next
> > kernel release. The idea is: instead of sending one AVTP packet at
> > every interval, the plugin will send several AVTP packets at once,
> > configuring their Tx time accordingly, so it can "sleep" for longer
> > periods of time. The goal is to ease on task scheduling by
> > offloading  packet transmissions to the NIC.
> 
> A feature to queue packets with a transmission timing is mandatory
> for
> applications to implement this kind of time-awareness packet
> transmission protocol on general purpose operating system which has
> less
> guarantees of its real-time capability.
> 
> In a case of IEC 61882-1/6 on IEEE 1394 bus, controllers of 1394
> OHCI[1]
> allows applications to queue several packets to corresponding
> isochronous cycle. As a result, the controller can transfer each
> packet
> at each isochronous cycle.
> 
>  From my curiousity, would I ask you to explain about usage of the
> ETF 'qdisk' for this kind of applications?

That patchset introduces the SO_TXTIME sockopt which enables user-space 
applications to specify when a given packet should be transmitted. The
ETF qdisc ensures that packets from multiple user-space applications
are sent to the network controller in the right order (earlest txtime
first). The controller then sends packets to the network at the txtime
configured by the user.

In the AAF plugin case, it will prepare several AVTPDUs, configure
their txtime so the transmission interval is respected, and offload
them to the kernel/NIC.

> How relevant hardware
> guarantees timing of transmission for queued packets?

In [1] you can find some performance measurements. The highlight is
"Using so_txtime, the peak to peak jitter is about 100 nanoseconds,
independent of the period."

> Or network stack
> on Linux kernel govern the transmission timing in the proposed
> patchset?[2].

If the NIC doesn't support the scheduled transmission feature, yes, the
kernel govern the transmission.

Hope this clarifies.

Regards,

Andre

[1] https://patchwork.ozlabs.org/cover/814802/	

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3262 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]