How long can an NDIS packet be held before completion?

NTDEV
1

Consider the Send routine of an NDIS miniport. The routine needs to queue
the packet, so it does, and then it returns NDIS_STATUS_PENDING.

I realize that the driver should return the packet “soon” to NDIS, using
NdisMSendComplete. But how soon? What happens (or doesn’t happen) while a
driver holds onto a packet buffer? Is there a maximum time?

– arlie

2

I was involved in a project in the NT4.0 days that would hold packets for
times up to 100ms before they were sent. Not sure if it helps but it is a
data point.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Arlie Davis” wrote in message
news:xxxxx@ntdev…
> Consider the Send routine of an NDIS miniport. The routine needs to queue
> the packet, so it does, and then it returns NDIS_STATUS_PENDING.
>
> I realize that the driver should return the packet “soon” to NDIS, using
> NdisMSendComplete. But how soon? What happens (or doesn’t happen) while
> a
> driver holds onto a packet buffer? Is there a maximum time?
>
> – arlie
>
>

3

I’ve looked into this a little bit. I have seen cases where a packet
indicated up to the TCP/IP is held indefinitely. I was able to reproduce
the behavior by opening a listening socket and then sending up a packet
to that socket. The receiver didn’t do the read until I released it and
the packet wasn’t completed back to me until I released the receiver. I
don’t recall if I did with UDP, TCP, or both. 'nother data point.

Aaron Stavens

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Friday, August 26, 2005 3:00 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] How long can an NDIS packet be held before completion?

Consider the Send routine of an NDIS miniport. The routine needs to
queue the packet, so it does, and then it returns NDIS_STATUS_PENDING.

I realize that the driver should return the packet “soon” to NDIS, using
NdisMSendComplete. But how soon? What happens (or doesn’t happen)
while a driver holds onto a packet buffer? Is there a maximum time?

– arlie

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Arlie,

All that happens is that the protocol that originated the packet will
experience a ?shortage? of packet descriptors. If your driver needs to
?delay? the packet for a long time, it is more neighborly to copy the packet
and queue the copy while returning the original packet back to the sender.
In this way you are consuming your own resources (and perhaps can monitor
the utilization of such resources) but returning the senders resource.

Of course there is no definition of long time. Moreover, the system should
not ?fail? even if the packet was kept for all eternity.

Pay attention to NDIS 5.1 ?cancel? semantics for sends. Of course you are
not required to support send cancellation but if you really are going to
queue the packets for a long time, you might consider supporting
cancellation.

Good Luck,

Dave Cattley

Consulting Engineer

Systems Software Development

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Friday, August 26, 2005 6:00 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] How long can an NDIS packet be held before completion?

Consider the Send routine of an NDIS miniport. The routine needs to queue
the packet, so it does, and then it returns NDIS_STATUS_PENDING.

I realize that the driver should return the packet “soon” to NDIS, using
NdisMSendComplete. But how soon? What happens (or doesn’t happen) while a
driver holds onto a packet buffer? Is there a maximum time?

– arlie

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

That sounds reasonable. What I was looking for was – what’s the worst
thing that could happen? So, starving protocols of packet descriptors
sounds bad, but not as bad as a bugcheck. Which is what I’m seeing from a
driver I’m trying to fix.

Thanks.

– arlie

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Friday, August 26, 2005 9:23 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How long can an NDIS packet be held before completion?

Arlie,

All that happens is that the protocol that originated the packet will
experience a ‘shortage’ of packet descriptors. If your driver needs to
‘delay’ the packet for a long time, it is more neighborly to copy the packet
and queue the copy while returning the original packet back to the sender.
In this way you are consuming your own resources (and perhaps can monitor
the utilization of such resources) but returning the senders resource.

Of course there is no definition of long time. Moreover, the system should
not ‘fail’ even if the packet was kept for all eternity.

Pay attention to NDIS 5.1 ‘cancel’ semantics for sends. Of course you are
not required to support send cancellation but if you really are going to
queue the packets for a long time, you might consider supporting
cancellation.

Good Luck,

Dave Cattley

Consulting Engineer

Systems Software Development

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Friday, August 26, 2005 6:00 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] How long can an NDIS packet be held before completion?

Consider the Send routine of an NDIS miniport. The routine needs to queue
the packet, so it does, and then it returns NDIS_STATUS_PENDING.

I realize that the driver should return the packet “soon” to NDIS, using
NdisMSendComplete. But how soon? What happens (or doesn’t happen) while a
driver holds onto a packet buffer? Is there a maximum time?

– arlie

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com