Re: NDIS functionality details

Tech-Archive recommends: Fix windows errors by optimizing your registry


<v_mirgorodsky@xxxxxxxxx> wrote in message news:1119386236.130332.158100@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
Hello Maxim,

Thanks for your answer.

Maxim S. Shatskih wrote:
Depends on module kind. In protocol - yes. In filter/IM - yes. In adapter
driver talking directly to hardware (like PCI) - the so-called miniport - no.
In adapter driver talking to underlying software (like USB) - the so-called
NDIS-WDM miniport - yes. 

Is there any strict rule, which defines what functions may be used
within NDIS driver and which should/must be avoided? Or this is just a
matter of experience?


If it is a true NDIS miniport, then NDIS functions only.

All others - try to use NDIS unless there is no alternative.

> 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?

It calls the miniport's TransferDataHandler. The latter copies the data from
the hardware to the protocol-provided NDIS_PACKET. 

So, in time I got the packet into my ProtocolReceivePacket() handler it
may not be even in physical memory? I am planning to do most of the
work through ProtocolReceivePacket() handler. Will it be optimal to
copy data to some bigger intermidiate buffer right away? The second
approach is to delay copying and overlap it with data processing later.
I expect to receive about 100MB of compressed data per second. Then I
need either decompress them in kernel thread or store them in
compressed form to disk. In any case saving on 200MB memory bandwidth
would be a big deel.

A NDIS protocol or the lower "protocol edge" of a NDIS IM driver has two possible callbacks for receiving packets:

1.) ProtocolReceive
2.) ProtocolReceivePacket

NdisTransferData is ONLY involved in the ProtocolReceive path. And even then only in cases where the underlying miniport really sucks. In ProtocolReceive you should first check to see if LookaheadBufferSize == PacketSize; if so, then you have the whole packet already available (combine HeaderBuffer+LookaheadBuffer) and there will be no need to call NdisTransferData at all.

On some old adapters (actually, old miniport drivers) you will find cases where LookaheadBufferSize < ProtocolSize. You must deal with this case by calling NdisTransferData.

A word or warning: Never assume that NdisGetReceivedPacket will be successful.

Packet data presented at the ProtocolReceive handler is ephemeral. If you want the data, you must make a copy before returning from your ProtocolReceive handler.

Now, when you are handling packets in the (optional) ProtocolReceivePacket handler you do NOT deal with NdisTransferData at all. You have the entire packet. And you can temporarily acquire possesion of the original packet by returning a non-zero value as described in the DDK.

Hope this helps.

Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com


--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@xxxxxxxxxxxxxxxx
http://www.storagecraft.com



.

Relevant Pages

  • Re: Receive send packet
    ... > a send packet by the stack. ... A protocol driver binds to this Miniport ...
    (microsoft.public.development.device.drivers)
  • Problem with the NDIS MUX IM driver (decapsulation not working)
    ... Running the driver on Win2003 machines. ... I slap on my own ethernet header infront of the real ... When my IM receives a packet ... (ProtocolReceivePacket, ProtocolReceive) ...
    (microsoft.public.development.device.drivers)
  • Re: NDIS behaviour
    ... The network driver is forwarding these packets to the network protocol stack ... network driver immediately regains ownership of the packet descriptor and all ... NDIS subsequently calls the miniport driver's MiniportReturnPacket function. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: NDIS behaviour
    ... The driver is checking the status upon return from the Indicate call. ... using the NdisMIndicateReceivePacket API. ... the observed working case behavior the control of the packet is returned ... NDIS subsequently calls the miniport driver's MiniportReturnPacket ...
    (microsoft.public.windowsce.platbuilder)
  • Re: NDIS Passthru
    ... ProtocolReceivePacket is an optional callback. ... For example, if your adapter's miniport driver uses the old-style NdisMEthIndicatePacket call to indicate packets, then your NDIS IM driver will be called at ProtocolReceive. ... If your adapter's miniport driver uses the new-style NdisMIndicateReceive packet call, then your NDIS IM driver will be called most often at the ProtocolReceivePacket callback. ... It depends, however, on how much time it takes to modify the packet. ...
    (microsoft.public.development.device.drivers)