locked
Get packets from NDIS Driver to Application RRS feed

  • Question

  • Hello Everyone!!

    I have a customized NDIS Driver (connectionless) and an application which can communicate with it, both on a x86 machine. I have added some custom OIDs to the NDIS driver so that the application can get the packets which the driver receives. As is the general rule, NDISUIO sits in-between them, and I am haing it the same way. With this setup, I am observing a significant amount of packet losses.
    I tested with prints put in NDISUIO.dll source code and could clearly observe that a single read operation consists of a total of 1 memory allocation, 3 memcpy(), a string copy operation and a free() at last. This all I am doubting for the performance degradation.

    Can anyone suggest a better way to get the packets from the driver to the application, or a way where we can skip NDISUIO layer??

    Thanks!

    Wednesday, February 5, 2014 10:29 AM

Answers

  • Paul,

    Thank you so much for responding. Actually we needed 802.11 packets, and raw packets do not support the other functionality needed for the application. So we could not proceed with this.

    Well, the issue seems resolved now as the packet losses have become minimal. And guess who the real culprit was? Prints! The one line print was making the processing slow! The machine which I am using has an Intel Atom processor. Still don't know why it was having this much of impact on the performance! Any guesses??

    Thanks!

    • Marked as answer by deepak_ Wednesday, February 12, 2014 8:59 AM
    Monday, February 10, 2014 11:22 AM

All replies

  • Why do you need the individual packets? You can sort of achieve that for IP traffic (datagram) through WinSock calls. I seem to remember RAW being supported in some drivers and versions of NDIS/WinSock.

    If datagrams won't do it, then I suppose you could queue the packets to be returned to application so they won't disappear before you call-in and retrieve them. I think it's the structure of your code that's the problem.

    Paul T.

    Thursday, February 6, 2014 11:23 PM
  • Paul,

    Thank you so much for responding. Actually we needed 802.11 packets, and raw packets do not support the other functionality needed for the application. So we could not proceed with this.

    Well, the issue seems resolved now as the packet losses have become minimal. And guess who the real culprit was? Prints! The one line print was making the processing slow! The machine which I am using has an Intel Atom processor. Still don't know why it was having this much of impact on the performance! Any guesses??

    Thanks!

    • Marked as answer by deepak_ Wednesday, February 12, 2014 8:59 AM
    Monday, February 10, 2014 11:22 AM
  • Prints to where? File? Well, file I/O is not instantaneous. Serial port? Even slower. Network debug connection? Not much better. Was the output data formatted (printing a string containing an integer, etc.)? That takes time, although not as much as waiting for disk I/O.

    Any wait-based activity can delay a time-critical thread.

    Paul T.

    Tuesday, February 11, 2014 11:04 PM
  • Paul,

    Thanks for responding..

    Yes, the output data was formatted and u guessed it right! It was printing a string containing an integer. The prints were coming on the console window, from where i run my application.
    Still i am observing few packet drops and planning to carve a parallel protocol driver out of NDISUIO. You can check my new thread on this.

    D


    • Edited by deepak_ Wednesday, February 12, 2014 9:01 AM
    Wednesday, February 12, 2014 8:59 AM