sync/async NdisTransferData()

Discussion in 'Windows Vista Drivers' started by Peter, Apr 5, 2005.

  1. Peter

    Peter Guest

    Hi,
    It would help me to hear one thing from programmer who has experiences
    with behaviour of many NIC types in NDIS environment.

    The problem is relating to NIC-s that uses old style of received packet
    indicating.
    In DDK doc is written that if NdisTransferData() returns NDIS_STATUS_PENDING,
    miniport driver after copying data calls ProtocolTransferDataComplete().

    I have tried only small amount of NIC types
    and by my small expierences NdisTransferData() always was executed
    synchronously.
    My question is:
    When NIC driver cannot copy all data in NdisTransferData() ?
    Is it depending on NIC type ? Or it is depending on lack of system resources
    ? or something other ?
    Or only old scrap taiwan NIC-s cannot catch to copy all data synchronously ?
    (Consider only on W2K/XP/2003 and up)

    The answer can help with my design/implementation.

    Thanks !
    Peter
     
    Peter, Apr 5, 2005
    #1
    1. Advertisements

  2. When NIC driver cannot copy all data in NdisTransferData() ?
    Yes. Some drivers can be really such.
     
    Maxim S. Shatskih, Apr 5, 2005
    #2
    1. Advertisements

  3. Peter

    Peter Guest

    Thanks for answer Maxim,
    I have some questions more relating to this.

    Are you 100% sure that reason can be only NIC driver ?

    It is important, because if yes then my customer can see dialog box with
    incompatibility with this driver. But if it is possible that NIC driver with
    quality NIC can process NdisTransferData() asynchronously (For example
    Intel10/100 Pro) I must to implement other code in my product to handle it.

    Peter
     
    Peter, Apr 5, 2005
    #3
  4. You must implement all code required by NDIS documentation, otherwise, you
    will have problems.
     
    Maxim S. Shatskih, Apr 5, 2005
    #4
  5. Peter

    Peter Guest

    Ok,
    I know what to implement but problem is for me testing in case of
    asynchronous NdisTransferData().
    Does exist way to force my NIC driver to asynchronous NdisTransferData()
    behavior ?

    Thanks !
    P.
     
    Peter, Apr 5, 2005
    #5
  6. Except then trying on many NICs of different generations - no other ways I
    think.
     
    Maxim S. Shatskih, Apr 5, 2005
    #6
  7. Peter

    Pavel A. Guest

    Hmm, good question. Perhaps a "delaying" passthru IM can help here
    (modify any available sample)
    --PA
     
    Pavel A., Apr 6, 2005
    #7
  8. Peter

    Steve Guest

    I think running HCT (used for getting driver signed) will
    generate all types of receive and allow your driver to be
    tested. Alternative is to write your own IM or NIC
    driver to simulate this.

    It is important that your driver is capable of processing
    all types - even if your user has a NIC that you specify,
    they might have other IM drivers installed (i.e. vpn -
    deterministic, etc.) and they might process receives
    using old style!

    Providing this support is not hard - email me if you need
    help - remove _ZXXZ_ for valid email address.

    Steve.
     
    Steve, Apr 6, 2005
    #8
  9. As others already said, there is now way around implementing
    ProtocolReceive(). This is *not* a question of how the NIC (i.e.
    miniport) driver passes received packets to NDIS. You will encounter
    your ProtocolReceive() handler getting invoked even if the underlying
    NIC driver does never call NdisIndicateReceive()! One reason is
    because of loopback packets.

    Anyway, the heart of your question is if and when
    ProtocolTransferDataComplete() is called asynchronously. Actually,
    that will happen if the underlying miniport driver needs to retrieve
    received packet data from the NIC asynchronously, e.g. via DMA. The
    card then usually requests an interrupt upon completion of the DMA
    transfer, which will in turn lead to the driver calling
    NdisMTransferDataComplete() and thus eventually
    ProtocolTransferDataComplete().

    The Microsoft NDIS Tester, which is part of the HCT (Hardware
    Compatibility Test), can be used to test NDIS miniports and IMs, but
    it cannot test NDIS protocols (see also
    http://www.wd-3.com/archive/NDISTest.htm).

    Stephan
     
    Stephan Wolf [MVP], Apr 6, 2005
    #9
  10. Peter

    Peter Guest

    Hi Stephan,
    Thanks for more light on this problem.
    Now I think only about second case - I am interest that you have written
    about DMA.
    Is that only case when NIC driver can process NdisTransferData()
    asynchronously ?
    (In other words: must NIC to support DMA to process NdisTransferData()
    asynchronously in it's driver ? )

    .... and thanks for link !
    P.
     
    Peter, Apr 7, 2005
    #10
  11. Peter

    Peter Guest

    Pavel, can you explain please what do you thing with "delaying passthru IM" ?
    (I know Passthru IM driver)
    Thanks !
    P.
     
    Peter, Apr 7, 2005
    #11
  12. Peter

    Peter Guest

    Hi Stephan,
    Thanks for more light on this problem.
    Now I think only about second case - I am interest that you have written
    about DMA.
    Is that only case when NIC driver can process NdisTransferData()
    asynchronously ?
    (In other words: must NIC to support DMA to process NdisTransferData()
    asynchronously in it's driver ? And only this type NIC do async transfer ? )

    .... and thanks for link !
    P.
     
    Peter, Apr 7, 2005
    #12
  13. Every NIC driver that uses NdisIndicateReceive() is free to process
    MiniportTransferData() asynchronously. That is not a question of
    whether the NIC is capable of DMA or not.

    Completing MiniportTransferData() asynchronously does however only
    make sense if the data is not available at the time
    MiniportTransferData() gets called. This is usually the case because
    the data needs to be transfered by some asynchronous mechanism, which
    is usually DMA.

    I recommend you do not make any assumptions about if or when a NIC
    driver treats MiniportTransferData() asynchronously. It's a much
    better idea to be able to properly handle such a case.

    But maybe gthat's your actual problem, i.e. you cannot *test* this
    feature in lack of a NIC that does do asynchronous
    MiniportTransferData().

    You can easily simulate such behaviour for instance as follows in your
    protocol driver:

    foo()
    {
    ...
    NdisTransferData(&Status, ...);
    if (Status == NDIS_STATUS_SUCCESS) {
    NDIS_SET_PACKET_STATUS(Packet, Status);
    <Put NDIS_PACKET in some queue, using e.g. the packet's
    'ProtocolReserved' field>
    }
    }

    Then have some timer callback retrieve the packet(s) from the queue
    and call ProtocolTransferDataComplete() from there. You can again use
    the packet's 'ProtocolReserved' field to save the required
    'ProtocolBindingContext' and 'BytesTransferred'. You can retrieve the
    also required packet status via NDIS_GET_PACKET_STATUS().

    Stephan
     
    Stephan Wolf [MVP], Apr 7, 2005
    #13
  14. MiniportTransferData() gets called. This is usually the case because
    DMA NIC drivers usually use the packet-based indication path, and thus no
    TransferData at all.
     
    Maxim S. Shatskih, Apr 7, 2005
    #14
  15. "Usually", yes. But I have written NDIS miniport drivers for NICs that
    do use DMA and still need to do their DMA transfers asynchronously.
    True for all slave DMA devices by design (ISA/EISA), but also for some
    DMA busmaster devices where each DMA transfer needs to be explicitly
    initiated by software (at the time the data is already available in
    some internal FIFO).

    This is in contrast to most (if not all) modern NICs, which are DMA
    busmasters (PCI). These devices use DMA descriptor lists and buffers
    that the software passes to them in advance. So the NIC can decide
    when to initiate a DMA transfer for a received packet.

    Stephan
     
    Stephan Wolf [MVP], Apr 8, 2005
    #15
  16. Peter

    Peter Guest

    But I have written NDIS miniport drivers for NICs that
    If you can tell me type of this NIC and I can somewhere to download
    your driver for it it can help me with testing.
    (I have tried NDISTest but I am more satisfied when I can test it in real
    conditions)

    Peter
     
    Peter, Apr 8, 2005
    #16
  17. Peter

    Peter Guest

    Let's assume that NdisTransferData() call has begun.
    This NdisTransferData() returns NDIS_STATUS_PENDING
    and NIC driver is doing some work and is going to call
    ProtocolTransferDataComplete().
    question:
    In this moment,
    is possible that next received packet is indicated to ProtocolReceive() by
    NIC driver
    before previous packet ProtocolTransferDataComplete() ?
    (between returning NdisTRansferData() and calling
    ProtocolNdisTransferDataComplete() )

    Thanks !
    Peter
     
    Peter, Apr 9, 2005
    #17
  18. Peter

    Peter Guest

    Hi Steve,
    I have tried NDISTest tool.
    Because I have poor equipment I run test on one machine,
    support interface with test interface are connected with cross-over cable.
    I choose CLIENT and 1 manual test named - "TransferData".
    I am not sure if this way is OK for testing async NdisTransferData(), but
    after test finished, the result was OK
    for my IM driver without implemented ProtocolTransferDataComplete()
    :-(

    P.
     
    Peter, Apr 9, 2005
    #18
  19. That depends on the setting of the NDIS_MAC_OPTION_RECEIVE_SERIALIZED
    flag returned by OID_GEN_MAC_OPTIONS. See the DDK docs for details.

    Please also take a look at the description of the
    NDIS_MAC_OPTION_TRANSFERS_NOT_PEND flag (also returned by
    OID_GEN_MAC_OPTIONS).
    Stephan
     
    Stephan Wolf [MVP], Apr 12, 2005
    #19
    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.