Re: NDIS functionality details



Hello Stephan,

Thanks for your answer.

In my driver I need to decompress compressed video data and provide
them to several Win32 application clients. If I put decompression task
for every client in system I will create significant overhead, if I try
to decompress data without using SIMD instructions, the process will
take too much time, using SIMD instructions in context of system thread
is not possible. This way kernel thread is the only solution and
Gigabit Ethernet is the only interface to accomodate 100MB/s data
throughput.

With best regards,
Vladimir S. Mirgorodsky

Stephan Wolf [MVP] wrote:
> v_mirgorodsky@xxxxxxxxx wrote:
> > NDIS subsystem exports a lot of functions with Ndis* prefix. Is it
> > possible to mix NDIS API with API, exported from NT kernel?
>
> Yes, you can use both NDIS and native system calls.
>
> > Will it
> > possibly introduce some incompatibility or runtime errors with future
> > OS upgrades?
>
> Yes, you will encounter incompatibilities.
>
> For NDIS miniports, using any non-NDIS functions makes the driver fail
> the official Microsoft WHQL certification, which is kind of a must for
> all commercial products.
>
> NDIS protocols can, however, also use native system calls.
>
> NDIS intermediate (IM) drivers also should not use non-NDIS functions.
>
> > For *example*, for my purposes I need to create a kernel
> > thread(s) to handle incoming data from network. NDIS does not provide
> > function for thread creation and scheduling work-items each time will
> > result in unnecessary overhead.
>
> In over 15 years of network driver development (over 10 years for NT) I
> have always managed to handle all network data in my drivers without
> creating any threads.
>
> If there is absolut need for asynchronous handling of network data in
> an NDIS driver, NDIS work items are usually sufficient.
>
> > What is the best strategy to handle incoming packets from the network?
> > DDK says, that there is two ways, one is to copy each packet to driver
> > allocated storage, another is to queue incoming packets and release
> > them later during processing phase. The second approach seems to be
> > more efficient, since there is no extra copy operation with data, but
> > it seems to be not safe, since underlying miniport NIC has allocated
> > only limited number of packets during initialization.
>
> Copying data is not state of the art. The receive functions providing
> lookahead data are just there for backward compatibility.
>
> > What actually happen during NdisTransferData() call? Does the function
> > actually copy data from source packet to destination packet or it just
> > copies the pointers to data buffers from source packet to destination
> > packet?
>
> NdisTransferData() is used to copy the forementioned old-fashion
> lookahead data.
>
> One still should support it, but I wouldn't put too much effort on it.
>
> Check the PASSTHRU and MUX samples in the DDK in order to see how one
> can cope with lookahead data.
>
> Stephan

.



Relevant Pages

  • Re: NDIS functionality details
    ... Maxim Shatskih, Windows DDK MVP ... >>> possible to mix NDIS API with API, ... using any non-NDIS functions makes the driver fail ... >>> DDK says, that there is two ways, one is to copy each packet to driver ...
    (microsoft.public.development.device.drivers)
  • Cannot receive faked UDP packet (from NDIS filter driver, using select & recvfrom)
    ... I have a NDIS filter driver sitting on top of Ethernet connections (based on ... Host_B replies with a TCP SYN ACK packet, which is trapped by the NDIS ... NDIS driver repackages the TCP packet in a UDP packet (changes are ...
    (microsoft.public.development.device.drivers)
  • Re: Question about modifing the NDIS packet?
    ... packet FROM a miniport BACK of the net. ... If your driver is an intermediate ... you driver changes the length of the ndis packet buffer - here you ... your driver is not a registered ndis driver. ...
    (microsoft.public.windowsxp.device_driver.dev)
  • Re: NDIS IM Driver - Handling odd 802.3 / Ethernet packets
    ... >I have recently come to question what the 'correct' behavior of an NDIS IM ... > sends a packet with 802.3 framing to the IM driver. ...
    (microsoft.public.development.device.drivers)
  • Re: Question about FILE_OBJECT
    ... NDIS IM is a driver that fully conforms to the model, ... I.E. every time they allocated a new context object they ...
    (microsoft.public.win32.programmer.kernel)