Best way to ensure ME..

NTDEV
1

Hi!
I need to protect some variables in my Ndis miniport driver between OID
and interrupt contexts.
What is the best way to ensure Mutual exclusion between OID context and
interrupt context.
Here, OID context runs at DPC_LEVEL so we can not acquire locks for
known time.
If we use spin lock its going to degrade system performance as i need
locking for more than 25 Us.
So, Can some one suggest me what is the best way to ensure ME in this case.

Thanks.

2

At DPC_LEVEL and interrupt level all you have is spin locks and interlocked
operations. What are you trying to do that has such a constraint?

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Raghu” wrote in message
news:xxxxx@ntdev…
> Hi!
> I need to protect some variables in my Ndis miniport driver between OID
> and interrupt contexts.
> What is the best way to ensure Mutual exclusion between OID context and
> interrupt context.
> Here, OID context runs at DPC_LEVEL so we can not acquire locks for known
> time.
> If we use spin lock its going to degrade system performance as i need
> locking for more than 25 Us.
> So, Can some one suggest me what is the best way to ensure ME in this
> case.
>
> Thanks.
>
>
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4143 (20090610)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

Information from ESET NOD32 Antivirus, version of virus signature database 4143 (20090610)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

3

Dear Burn,
Thanks for you reply.
My constraint is from my device, in OID path i have to do some
operations and wait for confirmation
from device and there are some variables which can be changed in both
contexts which need locking.

Thanks.

Don Burn wrote:

At DPC_LEVEL and interrupt level all you have is spin locks and interlocked
operations. What are you trying to do that has such a constraint?

4

Raghu wrote:

Dear Burn,
Thanks for you reply.
My constraint is from my device, in OID path i have to do some
operations and wait for confirmation
from device and there are some variables which can be changed in both
contexts which need locking.

Return NDIS_STATUS_PENDING, and later when the
data arrives from the device, call
NdisMSet/QueryInformationComplete.
You can’t hold the lock and wait in the OID path.

– pa

5

What about returning NDIS_STATUS_PENDING in the OID path and later use Set
or QueryInformation complete.
OID paths shud not hold for long.

Regards
Deepak

On Wed, Jun 10, 2009 at 7:05 PM, Raghu wrote:

> Dear Burn,
> Thanks for you reply.
> My constraint is from my device, in OID path i have to do some operations
> and wait for confirmation
> from device and there are some variables which can be changed in both
> contexts which need locking.
>
> Thanks.
>
>
> Don Burn wrote:
>
>> At DPC_LEVEL and interrupt level all you have is spin locks and
>> interlocked operations. What are you trying to do that has such a
>> constraint?
>>
>>
>>
>>
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

6

Thanks Pavel thats a good suggestion, i will try the same.

Pavel A. wrote:

Raghu wrote:
> Dear Burn,
> Thanks for you reply.
> My constraint is from my device, in OID path i have to do some
> operations and wait for confirmation
> from device and there are some variables which can be changed in both
> contexts which need locking.

Return NDIS_STATUS_PENDING, and later when the
data arrives from the device, call
NdisMSet/QueryInformationComplete.
You can’t hold the lock and wait in the OID path.

– pa

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

Thanks for the suggestion Deepak, i will try the same.

Deepak Gupta wrote:

What about returning NDIS_STATUS_PENDING in the OID path and later use
Set or QueryInformation complete.
OID paths shud not hold for long.

Regards
Deepak

On Wed, Jun 10, 2009 at 7:05 PM, Raghu
> mailto:xxxxx> wrote:
>
> Dear Burn,
> Thanks for you reply.
> My constraint is from my device, in OID path i have to do some
> operations and wait for confirmation
> from device and there are some variables which can be changed in
> both contexts which need locking.
>
> Thanks.
>
>
>
> Don Burn wrote:
>
> At DPC_LEVEL and interrupt level all you have is spin locks
> and interlocked operations. What are you trying to do that
> has such a constraint?
>
>
>
>
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
> and other seminars visit: http://www.osr.com/seminars To unsubscribe,
> visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx>

8

If you need to synchronize access to variables between any <= DISPATCH_LEVEL
path and the ‘true’ ISR path you must use either interlocked operations or
NdisMSyncronizeWithInterrupt() which will acquire the Interrupt SpinLock and
call back to a handler with the lock held.

If you are not really trying to synchronize with the MiniportISR but instead
are synchronizing access between MiniportHandleInterrupt (the DPC scheduled
to do the ISR work) then ‘normal’ spinlocks are your only choice unless
interlocked operations will cover your needs.

In either case, you cannot ‘wait’ for anything, only defer completion of the
request by returning NDIS_STATUS_PENDING from Miniport{Query|Set}Information
and later, from the MiniportHandleInterrupt(), calling
NdisM{Query|Set}InformationComplete().

Since MiniportISR is called at Device IRQL (> DISPATCH_LEVEL) you may not
call NdisM{Query|Set}InformationComplete() from the actual ISR.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Raghu
Sent: Wednesday, June 10, 2009 9:06 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Best way to ensure ME…

Hi!
I need to protect some variables in my Ndis miniport driver between OID
and interrupt contexts.
What is the best way to ensure Mutual exclusion between OID context and
interrupt context.
Here, OID context runs at DPC_LEVEL so we can not acquire locks for
known time.
If we use spin lock its going to degrade system performance as i need
locking for more than 25 Us.
So, Can some one suggest me what is the best way to ensure ME in this case.

Thanks.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

9

Thanks Dave.

David R. Cattley wrote:

If you need to synchronize access to variables between any <= DISPATCH_LEVEL
path and the ‘true’ ISR path you must use either interlocked operations or
NdisMSyncronizeWithInterrupt() which will acquire the Interrupt SpinLock and
call back to a handler with the lock held.

If you are not really trying to synchronize with the MiniportISR but instead
are synchronizing access between MiniportHandleInterrupt (the DPC scheduled
to do the ISR work) then ‘normal’ spinlocks are your only choice unless
interlocked operations will cover your needs.

In either case, you cannot ‘wait’ for anything, only defer completion of the
request by returning NDIS_STATUS_PENDING from Miniport{Query|Set}Information
and later, from the MiniportHandleInterrupt(), calling
NdisM{Query|Set}InformationComplete().

Since MiniportISR is called at Device IRQL (> DISPATCH_LEVEL) you may not
call NdisM{Query|Set}InformationComplete() from the actual ISR.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Raghu
Sent: Wednesday, June 10, 2009 9:06 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Best way to ensure ME…

Hi!
I need to protect some variables in my Ndis miniport driver between OID
and interrupt contexts.
What is the best way to ensure Mutual exclusion between OID context and
interrupt context.
Here, OID context runs at DPC_LEVEL so we can not acquire locks for
known time.
If we use spin lock its going to degrade system performance as i need
locking for more than 25 Us.
So, Can some one suggest me what is the best way to ensure ME in this case.

Thanks.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer