ClientEvent(Chained)Receive question

NTDEV
1

Is it appropriate to process the data indicated by the transport dirver
in the ClientEvent(Chained)Receive callback routine ? Or I should just
copy all the data from the buffer and return from these event handlers
as soon as possible? Which way can increase the network throughput?

Any help will be appreciated!

Best Regards,
hanzhu

2

Hanzhu,

It is appropriate to process the data in the event callback of a
ClientEventReceive if you can do so quickly. If you cannot do so quickly,
it is appropriate to buffer some, none, or all of the ‘look-ahead’ data in
the indication and return an IRP to get the remaining data; processing the
entire receive during the IRP completion routine.

I the case of the ‘Chained’ variety the client is being given what amounts
to be the underlying NDIS_PACKET and NDIS_BUFFER chain the resulted in
receive indication. Similar guidelines apply here. If it can be
accomplished quickly, you might as well get it done. If, however, it must
wait for some reason, you do not necessarily need to ‘copy’ the data since
it is permissible to hold onto ownership of the chained receive until
processing is complete. Of course you must realize that this cannot be for
a long time as you will starve the underlying NDIS NIC of receive buffers.

As for which way increases network throughput, are you asking for the system
in general or your application? If you know that your application is bursty
with low bandwidth requirements, then, perhaps buffering the recieves and
letting the system get back to more urgent tasks would be very considerate
of your driver. If, on the other hand, your application *is* the urgent
activity, it would be far better to get the processing done and not waste
time and resources buffering, queueing, scheduling, etc.

One last note: It is not *necessary* to register a ClientEventXxxChained
handler if nature of your driver is that it does not specifically take
advantage of the potential benefits (in other words, if it is just going to
buffer the data and schedule a work-item - you might as well allocate and
IRP and wait for the CRTN).

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hanzhu
Sent: Monday, December 05, 2005 9:01 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] ClientEvent(Chained)Receive question

Is it appropriate to process the data indicated by the transport dirver in
the ClientEvent(Chained)Receive callback routine ? Or I should just copy all
the data from the buffer and return from these event handlers as soon as
possible? Which way can increase the network throughput?

Any help will be appreciated!

Best Regards,
hanzhu

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@msn.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

3

Thank you for you suggestion! It really helps me a lot!

David R. Cattley wrote:

Hanzhu,

It is appropriate to process the data in the event callback of a
ClientEventReceive if you can do so quickly. If you cannot do so quickly,
it is appropriate to buffer some, none, or all of the ‘look-ahead’ data in
the indication and return an IRP to get the remaining data; processing the
entire receive during the IRP completion routine.

I the case of the ‘Chained’ variety the client is being given what amounts
to be the underlying NDIS_PACKET and NDIS_BUFFER chain the resulted in
receive indication. Similar guidelines apply here. If it can be
accomplished quickly, you might as well get it done. If, however, it must
wait for some reason, you do not necessarily need to ‘copy’ the data since
it is permissible to hold onto ownership of the chained receive until
processing is complete. Of course you must realize that this cannot be for
a long time as you will starve the underlying NDIS NIC of receive buffers.

As for which way increases network throughput, are you asking for the system
in general or your application? If you know that your application is bursty
with low bandwidth requirements, then, perhaps buffering the recieves and
letting the system get back to more urgent tasks would be very considerate
of your driver. If, on the other hand, your application *is* the urgent
activity, it would be far better to get the processing done and not waste
time and resources buffering, queueing, scheduling, etc.

One last note: It is not *necessary* to register a ClientEventXxxChained
handler if nature of your driver is that it does not specifically take
advantage of the potential benefits (in other words, if it is just going to
buffer the data and schedule a work-item - you might as well allocate and
IRP and wait for the CRTN).

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of hanzhu
Sent: Monday, December 05, 2005 9:01 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] ClientEvent(Chained)Receive question

Is it appropriate to process the data indicated by the transport dirver in
the ClientEvent(Chained)Receive callback routine ? Or I should just copy all
the data from the buffer and return from these event handlers as soon as
possible? Which way can increase the network throughput?

Any help will be appreciated!

–

Best Regards,
hanzhu

4

It is OK to process the data “in place”. But note - the receive event runs
on DISPATCH_LEVEL and cannot be blocked. Also note that the data pointers and
MDL chains from the event are no more valid at return from the event.

So, if you need any blocking long processing, you must copy the data to
your own buffers.

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

----- Original Message -----
From: “hanzhu”
To: “Windows System Software Devs Interest List”
Sent: Monday, December 05, 2005 5:01 PM
Subject: [ntdev] ClientEvent(Chained)Receive question

> Is it appropriate to process the data indicated by the transport dirver
> in the ClientEvent(Chained)Receive callback routine ? Or I should just
> copy all the data from the buffer and return from these event handlers
> as soon as possible? Which way can increase the network throughput?
>
> Any help will be appreciated!
> –
>
> _______________________________________________________
> Best Regards,
> hanzhu
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Hanzhu,

Please note that what Maxim has posted here about the validity of the MDL
chains is only true if the return from the ClientEventReceiveXxxChained() is
*not* STATUS_PENDING. If STATUS_PENDING is returned, the MDL chains
(NDIS_BUFFERs) are now ‘owned’ by the client and must be returned calling
TdiReturnChainedReceives() when processing is complete. This turns into
rather simply a call NdisReturnPackets() inside TDI.SYS. None the less, the
Tsdu remains valid until the call to TdiReturnChaainedReceives().

Maxim’s point about (potentially) being called at IRQL == DISPATCH_LEVEL is
very important. You cannot block a TDI ClientEventXxxx *ever*.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, December 05, 2005 3:41 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ClientEvent(Chained)Receive question

It is OK to process the data “in place”. But note - the receive event
runs on DISPATCH_LEVEL and cannot be blocked. Also note that the data
pointers and MDL chains from the event are no more valid at return from the
event.

So, if you need any blocking long processing, you must copy the data to
your own buffers.

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

----- Original Message -----
From: “hanzhu”
To: “Windows System Software Devs Interest List”
Sent: Monday, December 05, 2005 5:01 PM
Subject: [ntdev] ClientEvent(Chained)Receive question

> Is it appropriate to process the data indicated by the transport dirver
> in the ClientEvent(Chained)Receive callback routine ? Or I should just
> copy all the data from the buffer and return from these event handlers
> as soon as possible? Which way can increase the network throughput?
>
> Any help will be appreciated!
> –
>
> _______________________________________________________
> Best Regards,
> hanzhu
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@msn.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

> Please note that what Maxim has posted here about the validity of the MDL

chains is only true if the return from the ClientEventReceiveXxxChained() is
*not* STATUS_PENDING. If STATUS_PENDING is returned, the MDL chains
(NDIS_BUFFERs) are now ‘owned’ by the client and must be returned calling

Correct. But note - you cannot rely that all your receives will be chained. The
chained receive TDI event can be fired only if the packet arrived to the
protocol by means of ProtocolReceivePacket entry point, so that it is the
adapter who owns the NDIS_PACKET (note: the chained receive descriptor is
PNDIS_PACKET, and TdiReturnChainedReceives is NdisReturnPackets).

And, in turn, ProtocolReceivePacket can be called only from
NdisMIndicateReceivePacket, and even not in 100% of cases - sometimes
NdisMIndicateReceivePacket causes the old-style ProtocolReceive to be called
(due to NDIS_STATUS_RESOURCES, for instance).

So, your TDI client will see nonchained receive indications, and on some NICs
it will see 100% of them.

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

7

You really give me great help!
Thanks, Maxim and David!

Maxim S. Shatskih wrote:

> Please note that what Maxim has posted here about the validity of the MDL
> chains is only true if the return from the ClientEventReceiveXxxChained() is
> *not* STATUS_PENDING. If STATUS_PENDING is returned, the MDL chains
> (NDIS_BUFFERs) are now ‘owned’ by the client and must be returned calling

Correct. But note - you cannot rely that all your receives will be chained. The
chained receive TDI event can be fired only if the packet arrived to the
protocol by means of ProtocolReceivePacket entry point, so that it is the
adapter who owns the NDIS_PACKET (note: the chained receive descriptor is
PNDIS_PACKET, and TdiReturnChainedReceives is NdisReturnPackets).

And, in turn, ProtocolReceivePacket can be called only from
NdisMIndicateReceivePacket, and even not in 100% of cases - sometimes
NdisMIndicateReceivePacket causes the old-style ProtocolReceive to be called
(due to NDIS_STATUS_RESOURCES, for instance).

So, your TDI client will see nonchained receive indications, and on some NICs
it will see 100% of them.

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

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@gmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

–

Best Regards,
hanzhu