PCI Interrupt Latency
in [Device Drivers]
|
From: Marc on 7 Jul 2010 11:26 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
From: Don Burn on 7 Jul 2010 11:42 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 [mailto:Marc(a)discussions.microsoft.com] > 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 >
From: Maxim S. Shatskih on 7 Jul 2010 14:09 > 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 maxim(a)storagecraft.com http://www.storagecraft.com
From: Marc on 8 Jul 2010 02:58 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 [mailto:Marc(a)discussions.microsoft.com] > > 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 > > > > . >
From: Tim Roberts on 9 Jul 2010 01:36 Marc <Marc(a)discussions.microsoft.com> 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, timr(a)probo.com Providenza & Boekelheide, Inc.
|
Pages: 1 Prev: Removal of PDO Next: NdisAllocateNetBufferAndNetBufferList: Pool is NULL |