FYI: NDIS IM Drivers And NDIS Task Offload

NTDEV
1

Most NDIS IM driver developers encounter bizarre and unpredictable behavior
of their NDIS Intermediate (IM) drivers when operating on SOME NDIS
miniport drivers. The most common manifestation is often related to specific
adapters, but may be vague.

Complaints fall in the range:

1.) “Doesn’t work on certain adapters (frequently 3Com adapters).”
2.) “Can only send short packets”
3.) “Can browse the Internet, but not the Network Neighborhood”.

These problems may not appear in trivial PassThru NDIS IM driver samples
that simply re-wrap packets, but DO appear in non-trivial NDIS IM drivers.

It appears that this behavior is related to the NDIS Task Offload facility.

In an NDIS IM driver, calls to query and set OID_TCP_TASK_OFFLOAD should be
considered calls to the NDIS IM driver itself. From what I have found, an
NDIS IM driver should NOT blindly pass these OIDs (and other similar task
offload OIDs) to the lower NDIS miniport driver.

If an NDIS IM driver does not actually include code that specifically
implements NDIS Task Offload, then the NDIS IM driver should intercept task
offload query and set for OID_TCP_TASK_OFFLOAD (and similar) and fail them
by returning NDIS_STATUS_NOT_SUPPORTED.

If an NDIS IM driver actually does implement NDIS Task Offload, then it
should provide its own well-considered responses to these calls.

Of course, an NDIS IM driver can (and probably should) exploit the use of
the lower-level NDIS miniport’s NDIS Task Offload capabilities (if they
exist) in its own implementation of NDIS Task Offload support. However, this
requires more then simply passing the task offload OIDs blindly down. It
requires a good understanding of the task offload mechanism.

If anyone has something to add to this epistle, please do so.

I expect that Microsoft has a KB Article written in 1999 (or earlier) that
completely describes this problem and carefully describes the solution, but
I can’t find it… :slight_smile:

Regards,

Thomas F. Divine

PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - NDIS Intermediate - TDI Client
http: - http:

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:></http:>

2

Thomas,

By returning “Not Supported” to task off-load oids, you are disabling the
hardware built into the adapter. The whole purpose of this hardware is to
reduce the burden on the CPU by off-loading some tasks to the adapter. Now
you are putting the burden back on the CPU. Is this a good strategy?

Ed Hamlet

“Thomas F. Divine”
To: “NT Developers Interest List”
Sent by: cc:
xxxxx@lis Subject: [ntdev] FYI: NDIS IM Drivers And NDIS Task Offload
ts.osr.com

05/23/01 08:06 AM
Please respond to
“NT Developers
Interest List”

Most NDIS IM driver developers encounter bizarre and unpredictable behavior
of their NDIS Intermediate (IM) drivers when operating on SOME NDIS
miniport drivers. The most common manifestation is often related to
specific
adapters, but may be vague.

Complaints fall in the range:

1.) “Doesn’t work on certain adapters (frequently 3Com adapters).”
2.) “Can only send short packets”
3.) “Can browse the Internet, but not the Network Neighborhood”.

These problems may not appear in trivial PassThru NDIS IM driver samples
that simply re-wrap packets, but DO appear in non-trivial NDIS IM
drivers.

It appears that this behavior is related to the NDIS Task Offload facility.

In an NDIS IM driver, calls to query and set OID_TCP_TASK_OFFLOAD should be
considered calls to the NDIS IM driver itself. From what I have found, an
NDIS IM driver should NOT blindly pass these OIDs (and other similar task
offload OIDs) to the lower NDIS miniport driver.

If an NDIS IM driver does not actually include code that specifically
implements NDIS Task Offload, then the NDIS IM driver should intercept task
offload query and set for OID_TCP_TASK_OFFLOAD (and similar) and fail them
by returning NDIS_STATUS_NOT_SUPPORTED.

If an NDIS IM driver actually does implement NDIS Task Offload, then it
should provide its own well-considered responses to these calls.

Of course, an NDIS IM driver can (and probably should) exploit the use of
the lower-level NDIS miniport’s NDIS Task Offload capabilities (if they
exist) in its own implementation of NDIS Task Offload support. However,
this
requires more then simply passing the task offload OIDs blindly down. It
requires a good understanding of the task offload mechanism.

If anyone has something to add to this epistle, please do so.

I expect that Microsoft has a KB Article written in 1999 (or earlier) that
completely describes this problem and carefully describes the solution, but
I can’t find it… :slight_smile:

Regards,

Thomas F. Divine

PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - NDIS Intermediate - TDI Client
http: - http:

—
You are currently subscribed to ntdev as: xxxxx@conexant.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:></http:>

3

Certainly it is NOT desirable to disable NDIS Task Offload capability, if it
is provided by the underlying adapter.

I am saying that if a NDIS IM driver is not “NDIS Task Offload Aware”, then
blindly passing theses OIDs will cause unpredictable problems. The
higher-level NDIS protocol has effectively told the lower-level NDIS
miniport to manipulate packets in a way that the NDIS IM driver may not even
be aware of.

This is particularly of interest when a NDIS IM driver spontaneously
generates or completely clones packets - as is required in at least some
cases for non-trivial drivers. If NDIS Task Offload in involved, then use of
NDIS Task Offload effects the use of reserved fields in NDIS_PACKET in ways
that must be understood by the NDIS IM driver.

If the NDIS IM driver is to offer NDIS Task Offload support then the NDIS IM
must query the underlying NIC for the capabilities that may be available and
use them if desired.

Finally, I am saying that if your NDIS IM driver doesn’t have code that
explicitly handles NDIS Task Offload, then you should probably report it as
NDIS_STATUS_NOT_SUPPORTED.

Regards,

Thomas F. Divine

PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - NDIS Intermediate - TDI Client
http: - http:

----- Original Message -----
From:
To: NT Developers Interest List
Sent: Wednesday, May 23, 2001 12:14 PM
Subject: [ntdev] Re: FYI: NDIS IM Drivers And NDIS Task Offload

>
> Thomas,
>
> By returning “Not Supported” to task off-load oids, you are disabling the
> hardware built into the adapter. The whole purpose of this hardware is to
> reduce the burden on the CPU by off-loading some tasks to the adapter.
Now
> you are putting the burden back on the CPU. Is this a good strategy?
>
> Ed Hamlet
>
>
>
> “Thomas F. Divine”
> To: “NT Developers
Interest List”
> Sent by: cc:
> xxxxx@lis Subject: [ntdev] FYI:
NDIS IM Drivers And NDIS Task Offload
> ts.osr.com
>
>
> 05/23/01 08:06 AM
> Please respond to
> “NT Developers
> Interest List”
>
>
>
>
>
>
> Most NDIS IM driver developers encounter bizarre and unpredictable
behavior
> of their NDIS Intermediate (IM) drivers when operating on SOME NDIS
> miniport drivers. The most common manifestation is often related to
> specific
> adapters, but may be vague.
>
> Complaints fall in the range:
>
> 1.) “Doesn’t work on certain adapters (frequently 3Com adapters).”
> 2.) “Can only send short packets”
> 3.) “Can browse the Internet, but not the Network Neighborhood”.
>
> These problems may not appear in trivial PassThru NDIS IM driver samples
> that simply re-wrap packets, but DO appear in non-trivial NDIS IM
> drivers.
>
>
> It appears that this behavior is related to the NDIS Task Offload
facility.
>
>
> In an NDIS IM driver, calls to query and set OID_TCP_TASK_OFFLOAD should
be
> considered calls to the NDIS IM driver itself. From what I have found, an
> NDIS IM driver should NOT blindly pass these OIDs (and other similar
task
> offload OIDs) to the lower NDIS miniport driver.
>
> If an NDIS IM driver does not actually include code that specifically
> implements NDIS Task Offload, then the NDIS IM driver should intercept
task
> offload query and set for OID_TCP_TASK_OFFLOAD (and similar) and fail them
> by returning NDIS_STATUS_NOT_SUPPORTED.
>
> If an NDIS IM driver actually does implement NDIS Task Offload, then it
> should provide its own well-considered responses to these calls.
>
> Of course, an NDIS IM driver can (and probably should) exploit the use of
> the lower-level NDIS miniport’s NDIS Task Offload capabilities (if they
> exist) in its own implementation of NDIS Task Offload support. However,
> this
> requires more then simply passing the task offload OIDs blindly down. It
> requires a good understanding of the task offload mechanism.
>
>
> If anyone has something to add to this epistle, please do so.
>
> I expect that Microsoft has a KB Article written in 1999 (or earlier) that
> completely describes this problem and carefully describes the solution,
but
> I can’t find it… :slight_smile:
>
> Regards,
>
> Thomas F. Divine
>
> PCAUSA - Toolkits & Resources For Network Software Developers
> NDIS Protocol - NDIS Intermediate - TDI Client
> http: - http:
>
>
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@conexant.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@pcausa.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:></http:></http:></http:>