My IM driver repackages NDIS_BUFFERs of every incoming/outgoing packet
because it neededs to change it's content (NAT).
It creates copy of every NDIS_BUFFER in buffer chain, so length of every
result buffer copy is the same like in original buffer and number of copied
buffers is the same like number of original buffers.
For better performence in IM driver's filtering functions it should be fine
to have always buffer chain which contains only one buffer.

My question:

If code repackages buffers so that on input there are several NDIS_BUFFERS
and repackage buffer chain contains only one NDIS_BUFFER in chain, can it
have bad impact for processing by protocol drivers for incoming packets and
can it have bad impact for processing by ethernet driver for outgoing packets
?

Peter

No, it cannot, except the extra memcpy.

To avoid the extra memcpy, reuse the data portion of the original packet and
only fill the NATed header portion in it.

This is:
- allocate memory for the header portion
- fill it
- allocate 2 NDIS_BUFFERs for the header portion and the data portion
- the data portion's NDIS_BUFFER must describe the same memory as the original
NDIS_BUFFER chain, but with stepping up the header size from the beginning
- then allocate NDIS_PACKET, chain the buffers to it, and indicate up.

TCP/IP checksum offload will require separate handling.

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

Integration of incoming packet's buffers is always OK, but disintegration
may be dodgy - unless all incoming packet's headers are in its fist
NDIS_BUFFER, TCPIP is not going to recognize it. AFAIK, this behaviour
started off just as a bug in TCPIP, but subsequently turned into an
"official" feature....

Anton Bassov

"Maxim S. Shatskih" wrote:

More exactly - the first NDIS_BUFFER must be >= the lookahead size set by the
protocols.

TCPIP sets the lookahead size to maximum possible header size, and will fail if
the miniport violates the rule and the headers do not fit the first
NDIS_BUFFER.

Don't know. The lookahead size rule was always documented IIRC.

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

Maxim,


I am afraid you are confusing packet-based indications and media-specific
ones....

The very concept of lookahead buffer (and, hence, of
OID_GEN_CURRENT_LOOKAHEAD) applies only to media-specific indications,
because they may be partial. You don't deal with NDIS_BUFFERs when you do
media-specific indications - instead, if you made a partial indication, it is
protocol's responsibility to allocate NDIS_PACKET, attach NDIS_BUFFERs to it,
and pass it to NdisTransferData() so that your MPTransferData() handler can
copy data to it.

When you do packet-based indications, then, indeed, you have to deal with
NDIS_PACKETs and NDIS_BUFFERs. In such case you have to indicate the whole
packet, so that the concept of lookahead buffer just does not apply.....

Anton Bassov




"Maxim S. Shatskih" wrote:

No, for packet-based indications too. The first NDIS_BUFFER in the packet must
be >= OID_GEN_CURRENT_LOOKAHEAD.

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

AFAIK, originally the above was not an *official* requirement, although
drivers
that did not follow it just did not work properly, because TCPIP took only
the first buffer in a packet into consideration. Originally this "feature"
was thought of as of a bug in TCPIP, rather than intentional behaviour
However, subsequently it evolved into the official requirement.

In other words, MSFT found quite convenient way to "fix" a bug - it just
documented the bug, and presented it as an official requirement....

Anton Bassov

"Maxim S. Shatskih" wrote: