Re: NDIS functionality details
- From: v_mirgorodsky@xxxxxxxxx
- Date: 21 Jun 2005 14:01:55 -0700
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
.
- Follow-Ups:
- Re: NDIS functionality details
- From: Maxim S. Shatskih
- Re: NDIS functionality details
- References:
- NDIS functionality details
- From: v_mirgorodsky
- Re: NDIS functionality details
- From: Stephan Wolf [MVP]
- NDIS functionality details
- Prev by Date: Re: NDIS functionality details
- Next by Date: Re: NDIS functionality details
- Previous by thread: Re: NDIS functionality details
- Next by thread: Re: NDIS functionality details
- Index(es):
Relevant Pages
|