Question about MiniportOidRequest

Chakradhar_Kommuri · October 7, 2010, 3:15am

Hello Gurus,
The documentation says “NDIS calls MiniportOidRequest at IRQL <=
DISPATCH_LEVEL”.

I have following questions:

Is there a OID-IRQL mapping to know upfront about the IRQL expectaion for
particular OID?
What is the reason for varying IRQL for the same callback?

Regards,
Chakri

P.S.: I beg your pardon if these are too stupid questions.

Jeffrey_Tippet_MSFT · October 7, 2010, 5:35am

Your confusion is justified – this was a documentation bug. The docs have very recently been corrected. If you visit http://msdn.microsoft.com/en-us/library/ff559416(VS.85).aspx , you will see that it now correctly reads: " NDIS calls MiniportOidRequest at IRQL == PASSIVE_LEVEL ."

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Chakri
Sent: Thursday, October 07, 2010 12:15 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Question about MiniportOidRequest

Hello Gurus,
The documentation says “NDIS calls MiniportOidRequest at IRQL <= DISPATCH_LEVEL”.

I have following questions:

Is there a OID-IRQL mapping to know upfront about the IRQL expectaion for particular OID?
What is the reason for varying IRQL for the same callback?

Regards,
Chakri

P.S.: I beg your pardon if these are too stupid questions.

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

Chakradhar_Kommuri · October 7, 2010, 10:20am

Thanks for the clarification, Jeffery.

I see that the SDV shows “sdv irql current ==2” in the state window at the
beginning of MiniportOIDRequest. So, SDV needs to be corrected as well?

Regards,
Chakri

“Jeffrey Tippet” wrote in message
news:xxxxx@ntdev…
> Your confusion is justified – this was a documentation bug. The docs
> have very recently been corrected. If you visit
> http://msdn.microsoft.com/en-us/library/ff559416(VS.85).aspx , you will
> see that it now correctly reads: " NDIS calls MiniportOidRequest at IRQL
> == PASSIVE_LEVEL ."
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Chakri
> Sent: Thursday, October 07, 2010 12:15 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Question about MiniportOidRequest
>
> Hello Gurus,
> The documentation says “NDIS calls MiniportOidRequest at IRQL <=
> DISPATCH_LEVEL”.
>
> I have following questions:
> 1. Is there a OID-IRQL mapping to know upfront about the IRQL expectaion
> for particular OID?
> 2. What is the reason for varying IRQL for the same callback?
>
> Regards,
> Chakri
>
> P.S.: I beg your pardon if these are too stupid questions.
>
>
> —
> 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
>
>

David_R_Cattley · October 7, 2010, 10:34am

So does this mean that NDIS queues all ‘OID requests’ to be processed by a worker?

NdisOidRequest() can still be called at IRQL <= DISPATCH_LEVEL and so that pretty much means that no matter how trivial the processing a MP might implemenat an OID request with (like getting a statistic) which in the past might have reasonably assumed to be both safe and reasonable to just process without regard to IRQL is actually decoupled from the caller to and always run at PASSIVE_LEVEL?

This is a change from NDIS5 right?

Thanks,
Dave Cattley

From: xxxxx@microsoft.com
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] Question about MiniportOidRequest
Date: Thu, 7 Oct 2010 09:34:41 +0000

Your confusion is justified – this was a documentation bug. The docs have very recently been corrected. If you visit http://msdn.microsoft.com/en-us/library/ff559416(VS.85).aspx , you will see that it now correctly reads: " NDIS calls MiniportOidRequest at IRQL == PASSIVE_LEVEL ."

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Chakri
Sent: Thursday, October 07, 2010 12:15 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Question about MiniportOidRequest

Hello Gurus,
The documentation says “NDIS calls MiniportOidRequest at IRQL <= DISPATCH_LEVEL”.

I have following questions:

Is there a OID-IRQL mapping to know upfront about the IRQL expectaion for particular OID?

What is the reason for varying IRQL for the same callback?

Regards,
Chakri

P.S.: I beg your pardon if these are too stupid questions.

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

Jeffrey_Tippet_MSFT · October 7, 2010, 7:29pm

Yes, if NdisOidRequest is invoked at DISPATCH_LEVEL, a work item is queued to continue processing at PASSIVE_LEVEL. This is a change from the NDIS5 model, where we could call out to the miniport at DISPATCH_LEVEL, most obviously with serialized miniports.

However, you never had a guarantee that any type of OID would be completed synchronously at DISPATCH_LEVEL. The problem is that NDIS serializes OID requests, so a “fast” OID like OID_GEN_LINK_SPEED could get stuck behind a “slow” OID like OID_PNP_SET_POWER. Since the OID path is not meant to be a low-latency pipe, this is ok. (You’ll note that the timeout on an OID is measured in seconds, not microseconds.)

In NDIS6, we followed the philosophy of making it easier for miniports to write an MiniportOidRequest handler. We moved a lot of the “copy one integer” OIDs into NDIS itself (like OID_GEN_LINK_SPEED), so that they never even hit the miniport at all. Of the remaining OIDs that a miniport does need to implement, a fair number of them would require blocking (as OID_PNP_SET_POWER frequently does). So calling at PASSIVE_LEVEL and allowing miniports to block means that it simplifies their implementation; they don’t have to queue a workitem themselves.

NDIS 6.1 also introduces the Direct OID, which is designed for low-latency and (comparatively) high-volume operation. This takes a much shorter path through NDIS and can be completed synchronously at DISPATCH_LEVEL. If we’d had Direct OIDs all along, we might have made OID_GEN_STATISTICS go through that path, since the statistics fit well in that model.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David Cattley
Sent: Thursday, October 07, 2010 7:33 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Question about MiniportOidRequest

So does this mean that NDIS queues all ‘OID requests’ to be processed by a worker?

NdisOidRequest() can still be called at IRQL <= DISPATCH_LEVEL and so that pretty much means that no matter how trivial the processing a MP might implemenat an OID request with (like getting a statistic) which in the past might have reasonably assumed to be both safe and reasonable to just process without regard to IRQL is actually decoupled from the caller to and always run at PASSIVE_LEVEL?

This is a change from NDIS5 right?

Thanks,
Dave Cattley

From: xxxxx@microsoft.com mailto:xxxxx
> To: xxxxx@lists.osr.com mailto:xxxxx
> Subject: RE: [ntdev] Question about MiniportOidRequest
> Date: Thu, 7 Oct 2010 09:34:41 +0000
>
> Your confusion is justified – this was a documentation bug. The docs have very recently been corrected. If you visit http://msdn.microsoft.com/en-us/library/ff559416(VS.85).aspx , you will see that it now correctly reads: " NDIS calls MiniportOidRequest at IRQL == PASSIVE_LEVEL ."
>
> -----Original Message-----
> From: xxxxx@lists.osr.com mailto:xxxxx [mailto:xxxxx@lists.osr.com]mailto: On Behalf Of Chakri
> Sent: Thursday, October 07, 2010 12:15 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Question about MiniportOidRequest
>
> Hello Gurus,
> The documentation says “NDIS calls MiniportOidRequest at IRQL <= DISPATCH_LEVEL”.
>
> I have following questions:
> 1. Is there a OID-IRQL mapping to know upfront about the IRQL expectaion for particular OID?
> 2. What is the reason for varying IRQL for the same callback?
>
> Regards,
> Chakri
>
> P.S.: I beg your pardon if these are too stupid questions.
>
>
> —
> 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

—
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:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

Jeffrey_Tippet_MSFT · October 7, 2010, 7:40pm

Ah, ok thanks I will look into that.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Chakri
Sent: Thursday, October 07, 2010 7:20 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Question about MiniportOidRequest

Thanks for the clarification, Jeffery.

I see that the SDV shows “sdv irql current ==2” in the state window at the beginning of MiniportOIDRequest. So, SDV needs to be corrected as well?

Regards,
Chakri

“Jeffrey Tippet” wrote in message news:xxxxx@ntdev…
> Your confusion is justified – this was a documentation bug. The docs
> have very recently been corrected. If you visit
> http://msdn.microsoft.com/en-us/library/ff559416(VS.85).aspx , you
> will see that it now correctly reads: " NDIS calls MiniportOidRequest
> at IRQL == PASSIVE_LEVEL ."
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Chakri
> Sent: Thursday, October 07, 2010 12:15 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Question about MiniportOidRequest
>
> Hello Gurus,
> The documentation says “NDIS calls MiniportOidRequest at IRQL <=
> DISPATCH_LEVEL”.
>
> I have following questions:
> 1. Is there a OID-IRQL mapping to know upfront about the IRQL
> expectaion for particular OID?
> 2. What is the reason for varying IRQL for the same callback?
>
> Regards,
> Chakri
>
> P.S.: I beg your pardon if these are too stupid questions.
>
>
> —
> 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

David_R_Cattley · October 7, 2010, 8:14pm

Thanks for that expanded clarification.

Regarding the comment about blocking in MiniportOidRequest() ? are there any
guarantees about context here? Is it a work item (and thus system worker
thread), or a NDIS private worker thread? Blocking for long(er) periods
of time in a work-item has always been frowned on since it consumes a system
worker thread. Blocking in say an NDIS binding thread has always been ok
since NDIS is more or less expecting such behavior and accommodates that
with private thread resources.

Regards,

Dave Cattley

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Tippet
Sent: Thursday, October 07, 2010 7:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Question about MiniportOidRequest

Yes, if NdisOidRequest is invoked at DISPATCH_LEVEL, a work item is queued
to continue processing at PASSIVE_LEVEL. This is a change from the NDIS5
model, where we could call out to the miniport at DISPATCH_LEVEL, most
obviously with serialized miniports.

However, you never had a guarantee that any type of OID would be completed
synchronously at DISPATCH_LEVEL. The problem is that NDIS serializes OID
requests, so a ?fast? OID like OID_GEN_LINK_SPEED could get stuck behind a
?slow? OID like OID_PNP_SET_POWER. Since the OID path is not meant to be a
low-latency pipe, this is ok. (You?ll note that the timeout on an OID is
measured in seconds, not microseconds.)

In NDIS6, we followed the philosophy of making it easier for miniports to
write an MiniportOidRequest handler. We moved a lot of the ?copy one
integer? OIDs into NDIS itself (like OID_GEN_LINK_SPEED), so that they never
even hit the miniport at all. Of the remaining OIDs that a miniport does
need to implement, a fair number of them would require blocking (as
OID_PNP_SET_POWER frequently does). So calling at PASSIVE_LEVEL and
allowing miniports to block means that it simplifies their implementation;
they don?t have to queue a workitem themselves.

NDIS 6.1 also introduces the Direct OID, which is designed for low-latency
and (comparatively) high-volume operation. This takes a much shorter path
through NDIS and can be completed synchronously at DISPATCH_LEVEL. If we?d
had Direct OIDs all along, we might have made OID_GEN_STATISTICS go through
that path, since the statistics fit well in that model.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Cattley
Sent: Thursday, October 07, 2010 7:33 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Question about MiniportOidRequest

So does this mean that NDIS queues all ‘OID requests’ to be processed by a
worker?

NdisOidRequest() can still be called at IRQL <= DISPATCH_LEVEL and so that
pretty much means that no matter how trivial the processing a MP might
implemenat an OID request with (like getting a statistic) which in the past
might have reasonably assumed to be both safe and reasonable to just process
without regard to IRQL is actually decoupled from the caller to and always
run at PASSIVE_LEVEL?

This is a change from NDIS5 right?

Thanks,
Dave Cattley

From: xxxxx@microsoft.com
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] Question about MiniportOidRequest
Date: Thu, 7 Oct 2010 09:34:41 +0000

Your confusion is justified – this was a documentation bug. The docs have
very recently been corrected. If you visit
http://msdn.microsoft.com/en-us/library/ff559416(VS.85).aspx , you will see
that it now correctly reads: " NDIS calls MiniportOidRequest at IRQL ==
PASSIVE_LEVEL ."

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chakri
Sent: Thursday, October 07, 2010 12:15 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Question about MiniportOidRequest

Hello Gurus,
The documentation says “NDIS calls MiniportOidRequest at IRQL <=
DISPATCH_LEVEL”.

I have following questions:

Is there a OID-IRQL mapping to know upfront about the IRQL expectaion
for particular OID?

What is the reason for varying IRQL for the same callback?

Regards,
Chakri

P.S.: I beg your pardon if these are too stupid questions.

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

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

Jeffrey_Tippet_MSFT · October 7, 2010, 8:48pm

You are able to block for short, bounded durations, like issuing an URB to your hardware and waiting synchronously for the response. That’s normal and ok.

Where the wheels start to fall off the cart is not in tying up a threadpool’s threads, but actually in simply blocking other OIDs. Some OIDs, notably OID_GEN_STATISTICS, can be issued on the UI thread of GUIs. (It’s easy to dismiss that practice with “oh those careless UI programmers”, but it’s often inadvertent. For example, iphlpapi!GetIfTable2 ends up sending an OID or two, even though you might not immediately expect it). Therefore, if OID_GEN_STATISTICS is blocked behind some long-running OID, the UI will experience a microhang. It doesn’t matter, in this case, whether the long-running OID was spinning on a threadpool thread, or it used an elaborate pile of code to pend the request and complete it later asynchronously - in either case, the next OID in the queue still has to wait until the first is completed, and the GUI is blocked for the duration.

I don’t know if it was the original intention of the NDIS model that OIDs be fast enough to be issued on UI threads (measuring an OID’s Timeout in whole seconds seems somewhat quaint today), but that’s usermode has decided to do, so that’s what we have to live with.

You’ll note that, for operations that may be in-progress for an unbounded amount of time (e.g., the connection requested by OID_WWAN_CONNECT blocks on the network), the miniport is expected to complete the OID immediately with NDIS_STATUS_INDICATION_REQUIRED, and signal the actual completion of the operation later with a status indication. This little dance allows other OIDs to go through while the connection is being negotiated.

Incidentally, to answer your other question – the threadpool implementation depends on the OS. I think NDIS in Vista tended to use the system threadpool, while in Win7 it uses its own threadpool. There’s no particular guarantee on that, and it could change again.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Thursday, October 07, 2010 5:14 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Question about MiniportOidRequest

Thanks for that expanded clarification.

Regarding the comment about blocking in MiniportOidRequest() - are there any guarantees about context here? Is it a work item (and thus system worker thread), or a NDIS private worker thread? Blocking for long(er) periods of time in a work-item has always been frowned on since it consumes a system worker thread. Blocking in say an NDIS binding thread has always been ok since NDIS is more or less expecting such behavior and accommodates that with private thread resources.

Regards,
Dave Cattley

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Tippet
Sent: Thursday, October 07, 2010 7:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Question about MiniportOidRequest

Yes, if NdisOidRequest is invoked at DISPATCH_LEVEL, a work item is queued to continue processing at PASSIVE_LEVEL. This is a change from the NDIS5 model, where we could call out to the miniport at DISPATCH_LEVEL, most obviously with serialized miniports.

However, you never had a guarantee that any type of OID would be completed synchronously at DISPATCH_LEVEL. The problem is that NDIS serializes OID requests, so a “fast” OID like OID_GEN_LINK_SPEED could get stuck behind a “slow” OID like OID_PNP_SET_POWER. Since the OID path is not meant to be a low-latency pipe, this is ok. (You’ll note that the timeout on an OID is measured in seconds, not microseconds.)

In NDIS6, we followed the philosophy of making it easier for miniports to write an MiniportOidRequest handler. We moved a lot of the “copy one integer” OIDs into NDIS itself (like OID_GEN_LINK_SPEED), so that they never even hit the miniport at all. Of the remaining OIDs that a miniport does need to implement, a fair number of them would require blocking (as OID_PNP_SET_POWER frequently does). So calling at PASSIVE_LEVEL and allowing miniports to block means that it simplifies their implementation; they don’t have to queue a workitem themselves.

NDIS 6.1 also introduces the Direct OID, which is designed for low-latency and (comparatively) high-volume operation. This takes a much shorter path through NDIS and can be completed synchronously at DISPATCH_LEVEL. If we’d had Direct OIDs all along, we might have made OID_GEN_STATISTICS go through that path, since the statistics fit well in that model.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David Cattley
Sent: Thursday, October 07, 2010 7:33 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Question about MiniportOidRequest

So does this mean that NDIS queues all ‘OID requests’ to be processed by a worker?

NdisOidRequest() can still be called at IRQL <= DISPATCH_LEVEL and so that pretty much means that no matter how trivial the processing a MP might implemenat an OID request with (like getting a statistic) which in the past might have reasonably assumed to be both safe and reasonable to just process without regard to IRQL is actually decoupled from the caller to and always run at PASSIVE_LEVEL?

This is a change from NDIS5 right?

Thanks,
Dave Cattley

From: xxxxx@microsoft.com mailto:xxxxx
> To: xxxxx@lists.osr.com mailto:xxxxx
> Subject: RE: [ntdev] Question about MiniportOidRequest
> Date: Thu, 7 Oct 2010 09:34:41 +0000
>
> Your confusion is justified – this was a documentation bug. The docs have very recently been corrected. If you visit http://msdn.microsoft.com/en-us/library/ff559416(VS.85).aspx , you will see that it now correctly reads: " NDIS calls MiniportOidRequest at IRQL == PASSIVE_LEVEL ."
>
> -----Original Message-----
> From: xxxxx@lists.osr.com mailto:xxxxx [mailto:xxxxx@lists.osr.com]mailto: On Behalf Of Chakri
> Sent: Thursday, October 07, 2010 12:15 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Question about MiniportOidRequest
>
> Hello Gurus,
> The documentation says “NDIS calls MiniportOidRequest at IRQL <= DISPATCH_LEVEL”.
>
> I have following questions:
> 1. Is there a OID-IRQL mapping to know upfront about the IRQL expectaion for particular OID?
> 2. What is the reason for varying IRQL for the same callback?
>
> Regards,
> Chakri
>
> P.S.: I beg your pardon if these are too stupid questions.
>
>
> —
> 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

—
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

—
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:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

David_R_Cattley · October 8, 2010, 3:54pm

Thanks again for expanding and clarifying.

Cheers,

Dave Cattley

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Tippet
Sent: Thursday, October 07, 2010 8:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Question about MiniportOidRequest

You are able to block for short, bounded durations, like issuing an URB to
your hardware and waiting synchronously for the response. That?s normal and
ok.

Where the wheels start to fall off the cart is not in tying up a
threadpool?s threads, but actually in simply blocking other OIDs. Some
OIDs, notably OID_GEN_STATISTICS, can be issued on the UI thread of GUIs.
(It?s easy to dismiss that practice with ?oh those careless UI programmers?,
but it?s often inadvertent. For example, iphlpapi!GetIfTable2 ends up
sending an OID or two, even though you might not immediately expect it).
Therefore, if OID_GEN_STATISTICS is blocked behind some long-running OID,
the UI will experience a microhang. It doesn?t matter, in this case,
whether the long-running OID was spinning on a threadpool thread, or it used
an elaborate pile of code to pend the request and complete it later
asynchronously ? in either case, the next OID in the queue still has to wait
until the first is completed, and the GUI is blocked for the duration.

I don?t know if it was the original intention of the NDIS model that OIDs be
fast enough to be issued on UI threads (measuring an OID?s Timeout in whole
seconds seems somewhat quaint today), but that?s usermode has decided to do,
so that?s what we have to live with.

You?ll note that, for operations that may be in-progress for an unbounded
amount of time (e.g., the connection requested by OID_WWAN_CONNECT blocks on
the network), the miniport is expected to complete the OID immediately with
NDIS_STATUS_INDICATION_REQUIRED, and signal the actual completion of the
operation later with a status indication. This little dance allows other
OIDs to go through while the connection is being negotiated.

Incidentally, to answer your other question – the threadpool implementation
depends on the OS. I think NDIS in Vista tended to use the system
threadpool, while in Win7 it uses its own threadpool. There?s no particular
guarantee on that, and it could change again.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Thursday, October 07, 2010 5:14 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Question about MiniportOidRequest