I have a deserialized intermediate driver that accepts packets in
MiniportSendPackets, queues them, schedules a work item to do some processing
on them that has to happen at PASSIVE_LEVEL, and sets their status to
NDIS_STATUS_PENDING. The work item completes the packets once it is finished
processing.

This all works fine in low volume situations, but when I subject my driver
to one of the NDIS Test stress tests, I notice the following:
- MiniportSendPackets keeps getting called at DISPATCH_LEVEL and queueing
the packets;
- My work items never get a chance to run and complete the packets; and,
- Eventually I run out of buffer descriptors and I have to start setting
NDIS_STATUS_FAILURE on the packets in MiniportSendPackets.

I don't think there's a way to pause the execution of MiniportSendPackets
because it's getting called at DISPATCH_LEVEL. My question is: how can I
follow all the rules for MiniportSendPackets in this situation and still give
my work items a chance to complete the packets in a high volume situation?

Re: High Volume Queueing in NDIS MiniportSendPackets by Thomas

Thomas
Wed Jun 29 13:11:18 CDT 2005


"Geoffrey Kneller" <GeoffreyKneller@discussions.microsoft.com> wrote in
message news:CE4AB854-DEFE-4D76-A883-B6CFDBFC7B33@microsoft.com...
>I have a deserialized intermediate driver that accepts packets in
> MiniportSendPackets, queues them, schedules a work item to do some
> processing
> on them that has to happen at PASSIVE_LEVEL, and sets their status to
> NDIS_STATUS_PENDING. The work item completes the packets once it is
> finished
> processing.
>
> This all works fine in low volume situations, but when I subject my driver
> to one of the NDIS Test stress tests, I notice the following:
> - MiniportSendPackets keeps getting called at DISPATCH_LEVEL and queueing
> the packets;
> - My work items never get a chance to run and complete the packets; and,
> - Eventually I run out of buffer descriptors and I have to start setting
> NDIS_STATUS_FAILURE on the packets in MiniportSendPackets.
>
> I don't think there's a way to pause the execution of MiniportSendPackets
> because it's getting called at DISPATCH_LEVEL. My question is: how can I
> follow all the rules for MiniportSendPackets in this situation and still
> give
> my work items a chance to complete the packets in a high volume situation?

Apparently you are using some reqources of your own to queue the packets
passed into your MiniportSendPackets routine.

You can consider an alternative where you simply queue the original send
packet in a linked list of some sort. Since you are in the context of your
"miniport edge" you can use the two PVOIDs in the original NDIS_PACKET's
MiniportResereved field for queuing. This means that you will not have to
exhaust resources of your own to queue the temporarily packets as they enter
your MiniportSendPackets.

When you get a chance, fetch original packets from the linked list and
process them (including re-wrapping, etc.) at that later point.

Good luck,

Thomas F. Divine, Windows DDK MVP
http://www.rawether.net




Re: High Volume Queueing in NDIS MiniportSendPackets by GeoffreyKneller

GeoffreyKneller
Wed Jun 29 14:15:05 CDT 2005

Good idea! However, I'm guessing that what will happen if I implement that is
that NDIS will use up all its internal buffers instead of me using mine,
while I will still get a whole bunch of calls to MiniportSendPackets at
DISPATCH_LEVEL and never get a chance to start processing the packets in my
work items. Sooner or later someone's going to run out of resources unless I
can get NDIS to pause to allow the system worker thread to run.

"Thomas F. Divine [DDK MVP]" wrote:

>
> "Geoffrey Kneller" <GeoffreyKneller@discussions.microsoft.com> wrote in
> message news:CE4AB854-DEFE-4D76-A883-B6CFDBFC7B33@microsoft.com...
> >I have a deserialized intermediate driver that accepts packets in
> > MiniportSendPackets, queues them, schedules a work item to do some
> > processing
> > on them that has to happen at PASSIVE_LEVEL, and sets their status to
> > NDIS_STATUS_PENDING. The work item completes the packets once it is
> > finished
> > processing.
> >
> > This all works fine in low volume situations, but when I subject my driver
> > to one of the NDIS Test stress tests, I notice the following:
> > - MiniportSendPackets keeps getting called at DISPATCH_LEVEL and queueing
> > the packets;
> > - My work items never get a chance to run and complete the packets; and,
> > - Eventually I run out of buffer descriptors and I have to start setting
> > NDIS_STATUS_FAILURE on the packets in MiniportSendPackets.
> >
> > I don't think there's a way to pause the execution of MiniportSendPackets
> > because it's getting called at DISPATCH_LEVEL. My question is: how can I
> > follow all the rules for MiniportSendPackets in this situation and still
> > give
> > my work items a chance to complete the packets in a high volume situation?
>
> Apparently you are using some reqources of your own to queue the packets
> passed into your MiniportSendPackets routine.
>
> You can consider an alternative where you simply queue the original send
> packet in a linked list of some sort. Since you are in the context of your
> "miniport edge" you can use the two PVOIDs in the original NDIS_PACKET's
> MiniportResereved field for queuing. This means that you will not have to
> exhaust resources of your own to queue the temporarily packets as they enter
> your MiniportSendPackets.
>
> When you get a chance, fetch original packets from the linked list and
> process them (including re-wrapping, etc.) at that later point.
>
> Good luck,
>
> Thomas F. Divine, Windows DDK MVP
> http://www.rawether.net
>
>
>
>

Re: High Volume Queueing in NDIS MiniportSendPackets by pavel_a

pavel_a
Wed Jun 29 15:29:02 CDT 2005

"Geoffrey Kneller" wrote:
> Good idea! However, I'm guessing that what will happen if I implement that is
> that NDIS will use up all its internal buffers instead of me using mine,
> while I will still get a whole bunch of calls to MiniportSendPackets at
> DISPATCH_LEVEL and never get a chance to start processing the packets in my
> work items. Sooner or later someone's going to run out of resources unless I
> can get NDIS to pause to allow the system worker thread to run.

Geoffrey,
please note that one of purposes of the stress test is exactly
to see how your driver behaves when the system runs out of resources.
It should not crash; after the stress ends, all packets should be properly
completed.

Usually upper layers have some kind of flow control, so the size of send
queue is not
your problem.

You wrote that under normal load your driver behaves well, so if it passes
the stress successfully, may be you can leave it as is.

Regards
--PA

> "Thomas F. Divine [DDK MVP]" wrote:
>
> >
> > "Geoffrey Kneller" <GeoffreyKneller@discussions.microsoft.com> wrote in
> > message news:CE4AB854-DEFE-4D76-A883-B6CFDBFC7B33@microsoft.com...
> > >I have a deserialized intermediate driver that accepts packets in
> > > MiniportSendPackets, queues them, schedules a work item to do some
> > > processing
> > > on them that has to happen at PASSIVE_LEVEL, and sets their status to
> > > NDIS_STATUS_PENDING. The work item completes the packets once it is
> > > finished
> > > processing.
> > >
> > > This all works fine in low volume situations, but when I subject my driver
> > > to one of the NDIS Test stress tests, I notice the following:
> > > - MiniportSendPackets keeps getting called at DISPATCH_LEVEL and queueing
> > > the packets;
> > > - My work items never get a chance to run and complete the packets; and,
> > > - Eventually I run out of buffer descriptors and I have to start setting
> > > NDIS_STATUS_FAILURE on the packets in MiniportSendPackets.
> > >
> > > I don't think there's a way to pause the execution of MiniportSendPackets
> > > because it's getting called at DISPATCH_LEVEL. My question is: how can I
> > > follow all the rules for MiniportSendPackets in this situation and still
> > > give
> > > my work items a chance to complete the packets in a high volume situation?
> >
> > Apparently you are using some reqources of your own to queue the packets
> > passed into your MiniportSendPackets routine.
> >
> > You can consider an alternative where you simply queue the original send
> > packet in a linked list of some sort. Since you are in the context of your
> > "miniport edge" you can use the two PVOIDs in the original NDIS_PACKET's
> > MiniportResereved field for queuing. This means that you will not have to
> > exhaust resources of your own to queue the temporarily packets as they enter
> > your MiniportSendPackets.
> >
> > When you get a chance, fetch original packets from the linked list and
> > process them (including re-wrapping, etc.) at that later point.
> >
> > Good luck,
> >
> > Thomas F. Divine, Windows DDK MVP
> > http://www.rawether.net