You will usually never see any "overflow" situation on the send path.
If we are talking about real life networks, all protocols use a
request-respond mechanism. Thus, if the peer station is the "client"
and you are the "server", the peer will always request some data and
then wait for the response before requesting more data. Thus, your
send queue is already empty then. Same is true if you are the client.
The only exceptions I can think of is some streaming mechanism (e.g.,
a Video server) that does never wait for any requests. And of course
test environments/tools like NDISTest or TTCP (wsttcp, pcattcp, ntttcp
etc.).
Also, since one usually implements the send queue as a linked list (of
an infinite length) using the 'MiniportReserved' field of the
NDIS_PACKET, there is no need to worry about overflows in the
miniport. Thus, there should *never* be any reason for returning
NDIS_STAUS_RESOURCES from MiniportSend[Packets]().
If the link is down, return NDIS_STATUS_NO_CABLE, otherwise return
NDIS_STATUS_SUCCESS.
I doubt you will see your MiniportCancelSendPackets() handler getting
called in any normal situation. That is more likely to happen when the
user unbinds a protocol or shuts down the machine while any send
packets are still in your queue.
Running NDISTest against your miniport is probably the best way to
test and see if everything is fine with your send path (see e.g.
http://www.wd-3.com/archive/NDISTest.htm).
HTH, Stephan
---
On Tue, 9 Dec 2003 10:33:45 -0800, "Daum" <daum999@yahoo.com> wrote:
