PCI Interrupt Latency

Hi all,

I try to upgrade our WDM device driver to support PCI interrupts. This is
what I did so far to process an interrupt:
1) Connect the ISR-routine via IoConnectInterrupt() in the driver's
StartDevice-routine
2) Initialize a DpcForIsr-routine via IoInitializeDpcRequest() in the
driver's AddDevice-routine
3) Create a driver handle with FILE_FLAG_OVERLAPPED-flag in the MFC-app
4) Create an overlapped-event via CreateEvent(NULL, TRUE, FALSE, NULL) in
the MFC-app
5) Send the overlapped object to the driver via DeviceIoControl()
6) Mark the Irp pending via IoMarkIrpPending(), store the Irp to the
driver's DeviceExtension structure and return STATUS_PENDING in the driver's
DispatchIOCTL-routine
7) Wait for the Overlapped object to be completed via WaitForSingleObject in
the MFC-app
8) An edge triggered interrupt occurs
9) The ISR is called and it checks if the interrupt is from our PCI card,
calls the DpcForIsr via IoRequestDpc() and returns TRUE
10) The DpcForIsr-routine completes the stored (see 6) Irp via
IoCompleteRequest(), calls IoStartNextPacket() and returns
11) The WaitForSingleObject returns and the MFC-app continues working

The above cylcle works, but far too slow for our needs. I did some timing
measurements with following results:
- Time between 8 and 9: about 10 µs
- Time between 9 and 10: about 5 µs
- Time between 10 and 11: about 10 µs

So since most code is processed in kernel mode I really wonder about the
long latency. The above measurements mean that the time between an interrupt
and user mode app reaction is more than 25 µs.

Would one expect this timing or did I something wrong?

Thanks for your help!
Marc

> long latency. The above measurements mean that the time between an interrupt
> and user mode app reaction is more than 25 µs.
>
> Would one expect this timing or did I something wrong?

Microseconds? yes, I would expect this.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

Thanks for your reply!

The goal is to process a hardware event. When the event occurs, the hardware
should release the interrupt and the software then should collect a bunch of
data from the hardware. Of course this could be done all in kernel mode but
even the timing in kernel mode is not very satisfying. I really wonder why it
takes 10 microseconds for the ISR to start after the interrupt occurs and
then again 5 microseconds for the DPC to start.



"Don Burn" wrote:

> Actually, I am surprised you got that good of performance. Both the DPC
> times and the completion of the I/O request plus wait are actually very
> good. This is the reason most of us do not report interrupts to user
> space, there is latency. What is the goal here? Can you service the
> interrupt without going to user space?
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
> > -----Original Message-----
> > From: Marc [private.php?do=newpm&u=]
> > Posted At: Wednesday, July 07, 2010 11:27 AM
> > Posted To: microsoft.public.development.device.drivers
> > Conversation: PCI Interrupt Latency
> > Subject: PCI Interrupt Latency
> >
> > Hi all,
> >
> > I try to upgrade our WDM device driver to support PCI interrupts. This
> > is what
> > I did so far to process an interrupt:
> > 1) Connect the ISR-routine via IoConnectInterrupt() in the driver's
> > StartDevice-routine
> > 2) Initialize a DpcForIsr-routine via IoInitializeDpcRequest() in the
> > driver's
> > AddDevice-routine
> > 3) Create a driver handle with FILE_FLAG_OVERLAPPED-flag in the MFC-app
> > 4) Create an overlapped-event via CreateEvent(NULL, TRUE, FALSE, NULL)
> > in the
> > MFC-app
> > 5) Send the overlapped object to the driver via DeviceIoControl()
> > 6) Mark the Irp pending via IoMarkIrpPending(), store the Irp to the
> > driver's
> > DeviceExtension structure and return STATUS_PENDING in the driver's
> > DispatchIOCTL-routine
> > 7) Wait for the Overlapped object to be completed via
> > WaitForSingleObject in
> > the MFC-app
> > 8) An edge triggered interrupt occurs
> > 9) The ISR is called and it checks if the interrupt is from our PCI
> > card,
> > calls the DpcForIsr via IoRequestDpc() and returns TRUE
> > 10) The DpcForIsr-routine completes the stored (see 6) Irp via
> > IoCompleteRequest(), calls IoStartNextPacket() and returns
> > 11) The WaitForSingleObject returns and the MFC-app continues working
> >
> > The above cylcle works, but far too slow for our needs. I did some
> > timing
> > measurements with following results:
> > - Time between 8 and 9: about 10 µs
> > - Time between 9 and 10: about 5 µs
> > - Time between 10 and 11: about 10 µs
> >
> > So since most code is processed in kernel mode I really wonder about the
> > long
> > latency. The above measurements mean that the time between an interrupt
> > and
> > user mode app reaction is more than 25 µs.
> >
> > Would one expect this timing or did I something wrong?
> >
> > Thanks for your help!
> > Marc
> >
> >
> > __________ Information from ESET Smart Security, version of virus
> > signature
> > database 5259 (20100707) __________
> >
> > The message was checked by ESET Smart Security.
> >
> > http://www.eset.com
> >
>
> .
>

Marc <> wrote:
>
>The above cylcle works, but far too slow for our needs. I did some timing
>measurements with following results:
>- Time between 8 and 9: about 10 µs
>- Time between 9 and 10: about 5 µs
>- Time between 10 and 11: about 10 µs
>
>So since most code is processed in kernel mode I really wonder about the
>long latency. The above measurements mean that the time between an interrupt
>and user mode app reaction is more than 25 µs.

How did you measure this? With some methods of measuring elapsed time, it
takes multiple microseconds just to read the time. For example, if you are
using an I/O port to toggle a signal that you are monitoring on an
oscilloscope, the simple act of writing to an I/O port requires
microseconds.
--
Tim Roberts,
Providenza & Boekelheide, Inc.