(Q) Flow control between NDIS miniport driver and protocol driver.

Discussion in 'Windows Vista Drivers' started by Daum, Dec 9, 2003.

  1. Daum

    Daum Guest

    Subject : (Q) Flow control between de-serialized NDIS miniport driver and
    protocol driver.

    Hello everyone!

    I'm developing de-serialized NDIS Miniport driver at Win2K and WinXp.

    I'm worrying about if my Miniport receives more requests of
    MiniportSendPackets than it's throughput.

    If then, my Miniport's queue length will be longer and longer as time goes

    In that case, is it guarantee the protocol driver's issueing "CancelPacket"?

    Or, should my miniport returns status with NDIS_STAUS_RESOURCES as a
    parameter of NdisMSendComplete to resolve the situation of congestion?

    Thank you.

    Have a nice day.

    Daum, Dec 9, 2003
    1. Advertisements

  2. Daum

    Stephan Wolf Guest

    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

    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

    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.

    HTH, Stephan
    Stephan Wolf, Dec 10, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.