Hello,
I have following question to you NDIS-gurus. We have had discussions about
how the communication should work between miniport- and protocol-driver. The
problem is following:
I have a protocol driver that receives data through
ProtocolReceive-callback. All the data from miniport is placed in the
LookAheadBuffer but my protocol driver does not bother to copy the data to
its buffer, instead it calls NdisTransferData with offset as zero. This
causes crash in my system as the guy who has done the miniport.driver has
not provided the MiniportTransferData-routine. The argument for not
providing the function is that because he has given all the data already to
user in indicate-call’s LookAheadBuffer nobody should be calling the
NdisTransferData-function -> so it can be set to NULL.
DDK documentation is little bit vague about this as it mentioned in the
chapter 3.1.2.5 that you MUST provide this function but in everywhere else
it is pretty much said that you should not call NdisTransferData unless you
really have to. I know that at least packet-sample in DDK does always use
NdisTransferPacket-function.
Please give some opinions about the issue to clarify this design issue.
Best Regards, Mikko
I haven’t read the documentation in a while but I believe it was pretty
clear to me at the time that it was up to the protocol to copy the data
provided in the protocol recieve callback, then make a call to
NdisTransferData() to get the rest (if any). Expecting the adapter to hold
on to a packet after it has already given you one chance to get the data
“just in case” you want it later seems a little unfair to the miniport
writer. Buffers are usually a limited resource. Just my opinion.
I also provided the complete buffer to the ProtocolReceive routine. I was a
little nicer in that I did register a NdisTransferData() routine but I
always return failure to it because I don’t keep the data buffer around.
-----Original Message-----
From: xxxxx@nokia.com [mailto:xxxxx@nokia.com]
Sent: Thursday, October 19, 2000 8:06 AM
To: NT Developers Interest List
Subject: [ntdev] About NdisMEthIndicateReceive …
Hello,
I have following question to you NDIS-gurus. We have had discussions about
how the communication should work between miniport- and protocol-driver. The
problem is following:
I have a protocol driver that receives data through
ProtocolReceive-callback. All the data from miniport is placed in the
LookAheadBuffer but my protocol driver does not bother to copy the data to
its buffer, instead it calls NdisTransferData with offset as zero. This
causes crash in my system as the guy who has done the miniport.driver has
not provided the MiniportTransferData-routine. The argument for not
providing the function is that because he has given all the data already to
user in indicate-call’s LookAheadBuffer nobody should be calling the
NdisTransferData-function -> so it can be set to NULL.
DDK documentation is little bit vague about this as it mentioned in the
chapter 3.1.2.5 that you MUST provide this function but in everywhere else
it is pretty much said that you should not call NdisTransferData unless you
really have to. I know that at least packet-sample in DDK does always use
NdisTransferPacket-function.
Please give some opinions about the issue to clarify this design issue.
Best Regards, Mikko
You are currently subscribed to ntdev as: xxxxx@moore-solutions.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
Thanks for the feedback.
Only thing that I won’t get is that what you mean about keeping buffers.
When miniport calls NdisMEthIndicateReceive, the protocol driver will call
the NdisTransferData inside the ProtocolReceive-function synchronously so
there is no need for extra buffers -> no need to hold packets. I can
understand that LookHeadData might need to be copied in the ProtocolReceive
but I think the argument about buffers is invalid.
I think that registering transfer-function that returns an error is cool
trick so I might be using is as it does not matter if some protocol is not
supported by system but if it causes blue-screen it might make people really
unhappy.
-----Original Message-----
From: EXT xxxxx@moore-solutions.com
[mailto:xxxxx@moore-solutions.com]
Sent: Thursday, October 19, 2000 1:58 PM
To: NT Developers Interest List
Subject: [ntdev] RE: About NdisMEthIndicateReceive …
I haven’t read the documentation in a while but I believe it was pretty
clear to me at the time that it was up to the protocol to copy the data
provided in the protocol recieve callback, then make a call to
NdisTransferData() to get the rest (if any). Expecting the
adapter to hold
on to a packet after it has already given you one chance to
get the data
“just in case” you want it later seems a little unfair to the miniport
writer. Buffers are usually a limited resource. Just my opinion.
I also provided the complete buffer to the ProtocolReceive
routine. I was a
little nicer in that I did register a NdisTransferData() routine but I
always return failure to it because I don’t keep the data
buffer around.
-----Original Message-----
From: xxxxx@nokia.com [mailto:xxxxx@nokia.com]
Sent: Thursday, October 19, 2000 8:06 AM
To: NT Developers Interest List
Subject: [ntdev] About NdisMEthIndicateReceive …
Hello,
I have following question to you NDIS-gurus. We have had
discussions about
how the communication should work between miniport- and
protocol-driver. The
problem is following:
I have a protocol driver that receives data through
ProtocolReceive-callback. All the data from miniport is placed in the
LookAheadBuffer but my protocol driver does not bother to copy
the data to
its buffer, instead it calls NdisTransferData with offset as zero. This
causes crash in my system as the guy who has done the
miniport.driver has
not provided the MiniportTransferData-routine. The argument for not
providing the function is that because he has given all the
data already to
user in indicate-call’s LookAheadBuffer nobody should be calling the
NdisTransferData-function -> so it can be set to NULL.
DDK documentation is little bit vague about this as it mentioned in the
chapter 3.1.2.5 that you MUST provide this function but in
everywhere else
it is pretty much said that you should not call
NdisTransferData unless you
really have to. I know that at least packet-sample in DDK does
always use
NdisTransferPacket-function.
Please give some opinions about the issue to clarify this design issue.
Best Regards, Mikko
You are currently subscribed to ntdev as: xxxxx@moore-solutions.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
You are currently subscribed to ntdev as: xxxxx@nokia.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
Mikko,
NDIS4 and NDIS5 Miniports use NdisMIndicateReceivePacket(). From the DDK
for NdisMIndicateReceivePacket() :
"Any miniport driver that calls NdisMIndicateReceivePacket must
indicate full packets. Consequently, such a driver has no
MiniportTransferData function. "
So, the newer NDIS drivers call NdisMIndicateReceivePacket() rather than
NdisMEthIndicateReceive() and these drivers do not have a
MiniportTransferData function.
Regards,
Ed Hamlet
xxxxx@nokia
.com To: “NT Developers Interest List”
Sent by: cc:
xxxxx@lis Subject: [ntdev] RE: About NdisMEthIndicateReceive …
ts.osr.com
10/20/00 01:00 AM
Please respond to
“NT Developers
Interest List”
Thanks for the feedback.
Only thing that I won’t get is that what you mean about keeping buffers.
When miniport calls NdisMEthIndicateReceive, the protocol driver will call
the NdisTransferData inside the ProtocolReceive-function synchronously so
there is no need for extra buffers -> no need to hold packets. I can
understand that LookHeadData might need to be copied in the ProtocolReceive
but I think the argument about buffers is invalid.
I think that registering transfer-function that returns an error is cool
trick so I might be using is as it does not matter if some protocol is not
supported by system but if it causes blue-screen it might make people
really
unhappy.
- Mikko
>-----Original Message-----
>From: EXT xxxxx@moore-solutions.com
>[mailto:xxxxx@moore-solutions.com]
>Sent: Thursday, October 19, 2000 1:58 PM
>To: NT Developers Interest List
>Subject: [ntdev] RE: About NdisMEthIndicateReceive …
>
>
>I haven’t read the documentation in a while but I believe it was pretty
>clear to me at the time that it was up to the protocol to copy the data
>provided in the protocol recieve callback, then make a call to
>NdisTransferData() to get the rest (if any). Expecting the
>adapter to hold
>on to a packet after it has already given you one chance to
>get the data
>“just in case” you want it later seems a little unfair to the miniport
>writer. Buffers are usually a limited resource. Just my opinion.
>
>I also provided the complete buffer to the ProtocolReceive
>routine. I was a
>little nicer in that I did register a NdisTransferData() routine but I
>always return failure to it because I don’t keep the data
>buffer around.
>
>
>-----Original Message-----
>From: xxxxx@nokia.com [mailto:xxxxx@nokia.com]
>Sent: Thursday, October 19, 2000 8:06 AM
>To: NT Developers Interest List
>Subject: [ntdev] About NdisMEthIndicateReceive …
>
>
>Hello,
>
>I have following question to you NDIS-gurus. We have had
>discussions about
>how the communication should work between miniport- and
>protocol-driver. The
>problem is following:
>
>I have a protocol driver that receives data through
>ProtocolReceive-callback. All the data from miniport is placed in the
>LookAheadBuffer but my protocol driver does not bother to copy
>the data to
>its buffer, instead it calls NdisTransferData with offset as zero. This
>causes crash in my system as the guy who has done the
>miniport.driver has
>not provided the MiniportTransferData-routine. The argument for not
>providing the function is that because he has given all the
>data already to
>user in indicate-call’s LookAheadBuffer nobody should be calling the
>NdisTransferData-function -> so it can be set to NULL.
>
>DDK documentation is little bit vague about this as it mentioned in the
>chapter 3.1.2.5 that you MUST provide this function but in
>everywhere else
>it is pretty much said that you should not call
>NdisTransferData unless you
>really have to. I know that at least packet-sample in DDK does
>always use
>NdisTransferPacket-function.
>
>Please give some opinions about the issue to clarify this design issue.
>
>Best Regards, Mikko
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@moore-solutions.com
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>—
>You are currently subscribed to ntdev as: xxxxx@nokia.com
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
—
You are currently subscribed to ntdev as: xxxxx@conexant.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)