Re: NDIS ProtocolReceive - Is It Dead Yet?
- From: "Thomas F. Divine" <tdivine@NOpcausaSPAM>
- Date: Wed, 28 Mar 2007 01:23:23 -0400
ProtocolReceive is alive and well it you have a NDIS 5 protocol driver. On Vista it probably will be hard to find an adapter that exercises the abomination. I haven't run across one yet.
Certainly the NDIS 5 NDISPROT sample includes logic to deal with the abomination.
The "unnecessary" buffer allocation is due to a (design) fault in NdisTransferData. The "offset" field is specifically an offset into the source (received) packet data. Unfortunately, NdisTransferData does not feature an offset into the destination packet. The destination is always the first byte of the first buffer in the chain. The "unnecessary" buffer is allocated simply to force NdisTransferData into copying at an offset into the destination packet data.
Thomas F. Divine
"Le Chaud Lapin" <jaibuduvin@xxxxxxxxx> wrote in message news:1175054476.813789.172120@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I remember reading somewhere recently in this group that the
"abomination" of partial receives has been eliminated in Vista. Is
this true?
Also, it appears in the NDISPROT sample in the 2003 Server DDK that
the ProtocolReceive is doing unnecessary buffer allocation and
chaining in preparation to call NdisTransferData. Specifically, it
looks as if the ByteOffset field of NdisTransferData is not being
used. Instead, if a partial receive occurs, a new buffer is allocated
and chained to the packet even though the original buffer is large
enough to contain the entire packet. Why is the code written this
way? See code below:
-Le Chaud Lapin-
// Allocate resources for queueing this up.
//
pRcvPacket = ndisprotAllocateReceivePacket(
pOpenContext,
PacketSize + HeaderBufferSize, // <<<<<<<<<<
IS THIS NOT BIG ENOUGH?
&pRcvData
);
if (pRcvPacket == NULL)
{
Status = NDIS_STATUS_NOT_ACCEPTED;
break;
}
NdisMoveMappedMemory(pRcvData, pHeaderBuffer,
HeaderBufferSize);
//
// Check if the entire packet is within the lookahead.
//
if (PacketSize == LookaheadBufferSize)
{
NdisCopyLookaheadData(pRcvData+HeaderBufferSize,
pLookaheadBuffer,
LookaheadBufferSize,
pOpenContext->MacOptions);
//
// Queue this up for receive processing, and
// try to complete some read IRPs.
//
ndisprotQueueReceivePacket(pOpenContext, pRcvPacket);
}
else
{
//
// Allocate an NDIS buffer to map the receive area
// at an offset "HeaderBufferSize" from the current
// start. This is so that NdisTransferData can copy
// in at the right point in the destination buffer.
//
NdisAllocateBuffer(
&Status,
&pPartialNdisBuffer,
pOpenContext->RecvBufferPool,
pRcvData + HeaderBufferSize,
PacketSize);
if (Status == NDIS_STATUS_SUCCESS)
{
//
// Unlink and save away the original NDIS Buffer
// that maps the full receive buffer.
//
NdisUnchainBufferAtFront(pRcvPacket,
&pOriginalNdisBuffer);
NPROT_RCV_PKT_TO_ORIGINAL_BUFFER(pRcvPacket) =
pOriginalNdisBuffer;
//
// Link in the partial buffer for NdisTransferData to
// operate on.
//
NdisChainBufferAtBack(pRcvPacket, pPartialNdisBuffer);
DEBUGP(DL_LOUD, ("Receive: setting up for
TransferData:";
" Pkt %p, OriginalBuf %p, PartialBuf %p\n",
pRcvPacket, pOriginalNdisBuffer,
pPartialNdisBuffer));
NdisTransferData(
&Status,
pOpenContext->BindingHandle,
MacReceiveContext,
0, // ByteOffset
PacketSize,
pRcvPacket,
&BytesTransferred);
}
else
{
//
// Failure handled below in TransferDataComplete.
//
BytesTransferred = 0;
}
.
- References:
- NDIS ProtocolReceive - Is It Dead Yet?
- From: Le Chaud Lapin
- NDIS ProtocolReceive - Is It Dead Yet?
- Prev by Date: Re: System hang with ATI x1600 or x300 video card installed
- Next by Date: Re: DriverEntry returning success; still driver is not getting loaded.
- Previous by thread: NDIS ProtocolReceive - Is It Dead Yet?
- Next by thread: RE: NDIS ProtocolReceive - Is It Dead Yet?
- Index(es):
Relevant Pages
|
