Out of order packets from NDIS IM

Discussion in 'Windows Vista Drivers' started by Abhijit, Jun 23, 2004.

  1. Abhijit

    Abhijit Guest

    Hi All,

    DDK says:
    MiniportSendPackets receives an array of packet descriptors arranged
    in an order determined by the caller of NdisSendPackets. In __most
    cases__, the intermediate driver should maintain this ordering as it
    passes an incoming array of packets on to the underlying miniport
    driver. An intermediate driver that modifies per-packet information or
    OOB data in incoming packets before passing them on to the underlying
    driver might reorder an incoming array.


    Now what is this "most cases". Is it the case when "intermediate
    driver that modifies per-packet information or OOB data in incoming
    packets", or any IM driver (i.e. one not modifying the packets) ?


    In IM driver, in MiniportSendPackets routine I am cloning the packets
    (only TCP/UDP packets) and sending them after some processing. I may
    have to send the packets out of order due to the processing needs.
    Will everything work fine ? (I was thinking it must work fine, since
    IP (on which TCP/UDP rides) is capable of receiving packets out of
    order.)

    Any comments will be appreciated.

    TIA
    Abhijit
     
    Abhijit, Jun 23, 2004
    #1
    1. Advertisements

  2. NDIS is at LLC layer of OSI model, so, no packet ordering, it is not
    relevant for NDIS.
     
    Maxim S. Shatskih, Jun 23, 2004
    #2
    1. Advertisements

  3. Since you're passed an array, there's nothing to prevent you from changing
    the ordering of the packets in the array (or adding/dropping packets in the
    array) before you pass it on -- but to do so would be really the exception
    rather than the rule and would be really specific to the purpose of your IM
    driver. And, I would think, to do so would really confuse the receiving
    connection-oriented protocols and wouldn't do too much good to unreliable
    protocols.

    But, sure, you can change the order.

    Bryan S. Burgin


    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Bryan S. Burgin [MSFT], Jun 23, 2004
    #3
  4. TCP should be fine with the reorder, but chanses are you will break some
    datagram LAN specific application that will never expect out of order
    packets.


    !. And in anycase, lot of traffic should get to tcp in out of order, mostly
    because hop-by-hop routing !!!
    rights
     
    Alex the 1'th, Jun 23, 2004
    #4
  5. Abhijit

    Rohit Raina Guest

    In "most cases" IM drivers should maintain the order of packets (i.e send in
    the same order in which they received it), as it might be important to some
    protocols.

    other cases not covered under the "most cases" will be when you are
    implementing packet prioritization like: implementing 802.1P/Q packet
    priority (like QoS etc). In those cases, you need to send higher priority
    packets ahead of the lower priority packets.

    -Rohit Raina
    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Rohit Raina, Jun 23, 2004
    #5
  6. I shouldn't have said "confuse", but rather, "work harder" as it would
    force retries and sequencing for a particular data scheme. As Rohit
    pointed out, there are some reasons you might based on your driver's
    purpose. But in general you should keep the integrity of the order.

    Bryan S. Burgin


    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Bryan S. Burgin [MSFT], Jun 24, 2004
    #6
  7. Abhijit

    Stephan Wolf Guest

    Jumping into this discussion tardily, I agree with Rohit that packet
    prioritizing will of course change packet order (see e.g.
    NDIS_PACKET_8021Q_INFO and
    http://msdn.microsoft.com/library/e..._716fe071-3662-47f3-bacd-5eb6004a88c7.xml.asp).

    However, one should *never* change the order of packets that have the
    same priority. It used to be a known problem (back in these old days)
    that NetBEUI crashes when the order of packets gets changed. Although
    this was clearly an implementation bug, performance will probably
    suffer e.g. for most TCP implementations. (It is IMHO a fairytale that
    most current TCP implementations can cope with misordered packets.)

    Also, why would one ever need to change the order? Is that something
    like when one wants to spend one's change first before the bills?

    Stephan
    ---
     
    Stephan Wolf, Jun 29, 2004
    #7
    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.