Sorry, had to ask the packet handling questions to be sure I understood your
symptoms.
Are there any IM drives bound between your protocol and the NIC?
When you say that the packet is sent twice, where are you ‘measuring’ this?
Is it at the receiver or with Netmon/Ethereal on the sender?
Regarding OID_GEN_MAXIMUM_SEND_PACKETS -
OID_GEN_MAXIMUM_SEND_PACKETS
For Serialized Miniport Drivers
The OID_GEN_MAXIMUM_SEND_PACKETS OID specifies the maximum number of send
packet descriptors that a miniport driver’s MiniportSendPackets function can
accept in the array at its PacketArray parameter. NDIS will not call the
miniport driver’s MiniportSendPackets function with more than this number of
packets in the array at PacketArray.
If the underlying driver has only a MiniportSend function, it should return
one for this query. In this case, NDIS will always pass one packet to the
array at PacketArray.
Legacy NIC drivers usually return NDIS_STATUS_NOT_SUPPORTED for this query.
If a protocol, when calling NdisSendPackets, sends more packets in the
packet array than a miniport driver indicates that it can handle, NDIS
breaks the incoming packet array into smaller arrays and then calls the
miniport driver’s MiniportSendPackets function multiple times. It may be
more optimal for the miniport driver to handle this situation?that is, to
break down the packet array into smaller packet arrays, thereby eliminating
multiple calls to its MiniportSendPackets function.
For Deserialized Miniport Drivers
NDIS ignores any value returned by a deserialized driver in response to a
query of OID_GEN_MAXIMUM_SEND_PACKETS. NDIS does not adjust the size of the
array of packet descriptors that it supplies to a deserialized miniport’s
MiniportSendPackets function.
However, it is a bit terse and potentially confusing as it is written from
the perspective of a Miniport author and not the Protocol author. It does
not say that a protocol must not send more than this value. In fact, in a
serialized miniport, NDIS itself spoon-feeds the miniport in chunks thus
allowing a Protocol to send as many packets in the NdisSendPackets() call as
it pleases. This sets up the very likely possiblity that:
A) Protocol authors have no requirement to limit send blocks to <=
OID_GEN_MAXIMUM_SEND_PACKETS
B) Casually written *deserialized* Miniports do not handle (because the do
not expect) this case.
The answer is likely to be something to the effect of “do what TCPIP.SYS
does” (whatever that is).
Perhaps Thomas or one of our SMFT NDIS regulars knows the bottom line answer
on this one (Elias?)
I don’t recall the chipset for the D-Link (RTK8169?) and yours may differ.
But the fact that the Intel works (as expected) makes me think you are not
doing anything terrible. Perhaps the BCM driver owner will comment on the
behavior observed in the 570x.
Good Luck,
Dave Cattley
Constlting Engineer
Systems Software Development
