[Fwd: Re: PCI Multimedia Class Interrupt Priorities [PSARC/2008/343 FastTrack timeout 06/03/2008]]

[Wesley Shao]

Today, 7 or 8 doesn't make much difference since practically no one is
using 7 or 8. Some bus controllers are defaulted to use 9 because they
could be proxy-ing interrupts on other devices behalf, but that is
just the original intent and isn't known for sure.

Going forward, for DMA devices, we need to push them as low as they can.
As long as audio is above 6, we shouldn't be breaking any relative
priority (thus causing performance differentiations, or video goes out
of sync with audio).

On a side note, we should move the rest of the 9 crowd (bridges, etc) to
8 and leave 9 for error handling. Currently error handling is above lock
level and we are having major issues with it. That would be a different
case though.

In short, I think 7 is a better fit for audio.

Wes

Garrett D'Amore wrote:
> Resending, since I forgot to add the CC to PSARC!  Doh!
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: PCI Multimedia Class Interrupt Priorities [PSARC/2008/343 
> FastTrack timeout 06/03/2008]
> From:
> Garrett D'Amore <gdamore at sun.com>
> Date:
> Wed, 28 May 2008 13:04:06 -0700
> To:
> Wesley Shao <Wesley.Shao at Sun.COM>
>
> To:
> Wesley Shao <Wesley.Shao at Sun.COM>
>
>
> Wesley Shao wrote:
>> I can't think of reasons for below audio and above networking. Modern
>> audio devices (especially the HD ones) are all DMA based, interrupt
>> priority becomes relatively less important. I would like to push for 7
>> if we can.
> Why? (I can't think of reasons either, but then again I can't think of 
> reasons for between audio and lock level.)
>
> Put another way, I'm not sure we buy anything by further reducing the 
> level below 8.
>
> I can definitely think of good reasons why even with DMA, interrupts 
> needs to be serviced in a timely fashion.  (Synchronization of audio 
> with video, games, etc. as one example.  Certain kinds of low latency 
> applications such as echo cancellation, and VoIP processing, are other 
> examples where one wants to make sure that the processing latency is 
> as low as we can easily make it.)
>
> Btw, I'm putting PSARC back on the distribution list for this, as this 
> discussion really needs to be recorded in the case log.
>
> At ARC today, this case was approved for level 8.  Its probably a 
> minor update if we think we should move to level 7, but I am a bit 
> more hesitant there, given the need for audio drivers to get serviced 
> promptly.
>
>    -- Garrett
>>
>> Wes
>>
>> Garrett D'Amore wrote:
>>> Wesley Shao wrote:
>>>> Why not making it even lower, like 7 or 8? There are virtually no 
>>>> drivers
>>>> using 7 or higher. That will give some breathing room in case we 
>>>> have to
>>>> debug some drivers and want to put them between audio and 10.
>>>
>>> I'm open to this idea.  Level 9 was what was already in use, and 
>>> seemed to be well tested, which is why I proposed it.  But I'd be 
>>> happy to use 8, as well.  I don't think audio drivers have any 
>>> dependencies on any other drivers/devices, apart from typical 
>>> lock-oriented dependencies upon the system timer.
>>>
>>> Using 8 allows 7 to be used for things that are "just below" audio, 
>>> and 9 to be used for things that are "just above".  (I can't think 
>>> of any examples of either one of those... but maybe someday someone 
>>> else will.)
>>>
>>> Does anyone else have any thoughts?
>>>
>>>    -- Garrett
>>>>
>>>> Wes
>>>>
>>>> Garrett D'Amore - sun microsystems wrote:
>>>>> I'm submitting this fast-track case on my own behalf.  It probably 
>>>>> could
>>>>> qualify for self-review, but I want to give any interested parties 
>>>>> a chance
>>>>> to comment.
>>>>>
>>>>> Requested binding is Patch on the basis that no real interfaces 
>>>>> are changing,
>>>>> although realistically there is probaby little chance that we'll 
>>>>> backport this
>>>>> to S10.
>>>>>
>>>>> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
>>>>> This information is Copyright 2008 Sun Microsystems
>>>>> 1. Introduction
>>>>>     1.1. Project/Component Working Name:
>>>>>      PCI Multimedia Class Interrupt Priorities
>>>>>     1.2. Name of Document Author/Supplier:
>>>>>      Author:  Garrett D'Amore
>>>>>     1.3  Date of This Document:
>>>>>     27 May, 2008
>>>>> 4. Technical Description
>>>>>
>>>>> Fast-track: PCI Multimedia Class Interrupt Priorities
>>>>> Requested Binding: Patch
>>>>>
>>>>> Problem
>>>>> -------
>>>>>
>>>>> The current Solaris PCI nexus logic assigns high level interrupts 
>>>>> (level 12)
>>>>> to devices that are in PCI class 4 (multimedia class).  This 
>>>>> includes all
>>>>> audio devices.  (Most of which are either subclass 1 for legacy audio
>>>>> devices, or 3 for newer hdaudio compliant devices.)
>>>>>
>>>>> However, none of the current Solaris device drivers can operate 
>>>>> with such
>>>>> high interrupt priorities.  All of the audio drivers in Solaris 
>>>>> wind up
>>>>> reassigning an interrupt priority of 9 using the undocumented 
>>>>> property
>>>>> "interrupt-priorities" in their driver.conf(4) to overcome this 
>>>>> problem.
>>>>>
>>>>> (Recall that priority 10 is "lock level", the level above which 
>>>>> device drivers
>>>>> must not use locks or other constructs which could result in 
>>>>> putting a thread
>>>>> to sleep.)
>>>>>
>>>>> The project team is unaware of device drivers for any hardware in the
>>>>> multimedia class *other* than audio devices.
>>>>>
>>>>> The new audio framework proposed in PSARC 2008/318 will also be 
>>>>> unable to
>>>>> function with high-level interrupts.
>>>>>
>>>>> Solution
>>>>> --------
>>>>>
>>>>> We propose to change the default interrupt-priority for all 
>>>>> devices in the
>>>>> multimedia class (PCI class 4) to 9.  Experience has shown that this
>>>>> level is sufficiently high to meet the needs of low-latency audio 
>>>>> devices,
>>>>> without requiring extraordinary measures normally required when 
>>>>> dealing with
>>>>> high-level interrupts.
>>>>>
>>>>> As indicated, we are unaware of any devices supported by Solaris 
>>>>> that are in
>>>>> the multimedia class other than those associated with audio support.
>>>>>
>>>>> 6. Resources and Schedule
>>>>>     6.4. Steering Committee requested information
>>>>>        6.4.1. Consolidation C-team Name:
>>>>>         ON
>>>>>     6.5. ARC review type: FastTrack
>>>>>     6.6. ARC Exposure: open
>>>>>
>>>>>   
>>>
>
>