NDIS 6.8x LWF, Windows 10/11. The filter sits above Intel NICs and consumes a
GigE Vision image stream: it copies the payload into its own buffers and does not
pass those NBLs up the stack. Everything else is indicated upward.
The bug we already fixed: in FilterReceiveNetBufferLists the filter unlinked the
consumed NBLs from the indicated chain and returned with the chain split, including
on indications carrying NDIS_RECEIVE_FLAGS_RESOURCES. On a setup where the miniport
sets that flag on most indications, the miniport reclaimed only what it could still
reach from the head it had handed over. Unreclaimed buffers accumulated and the port
stopped receiving. Instrumentation showed the unreachable-NBL counter stopping at
2,033 with Receive Buffers configured to 2,048, at the moment the port went silent.
Our fix: on a RESOURCES indication we no longer rebuild the chain - we process the
image NBLs in place and indicate the original chain upward unchanged, exactly as the
pre-optimisation code did.
Three things I would like opinions on.
-
Pattern. For an LWF that must keep some NBLs out of the upper stack, what do
people consider the sanctioned pattern on a RESOURCES indication? The options I
see are (a) indicate the full original chain upward and accept that the consumed
packets also reach the stack, (b) split, indicate the remainder, then relink the
original chain before returning, (c) copy out and originate a fresh indication
with filter-allocated NBLs. (b) looks correct per the docs but seems fragile:
the upper layers may have touched Next pointers by the time
NdisFIndicateReceiveNetBufferLists returns for a RESOURCES indication. Is (b)
actually safe, or is (a)/(c) what people ship? -
Miniport behaviour. On the I350, the share of indications carrying the flag is
not stable across boots on the same machine with identical settings: some boots
are near zero, others 34% to 100%. X550, I226 and an AQC107 stay below 0.03% in
every run we did. Has anyone seen a miniport swing like this, and is there a
known mechanism (descriptor/queue allocation at init, RSS layout, teaming) behind
it? The high-ratio runs all had the adapter in an MS switch team, but a teamed
X550 stayed low, so teaming alone does not explain it. -
Detection. Is there any way to catch "filter returned a mangled chain on a
RESOURCES indication" other than instrumenting the filter itself? Verifier's
NDIS rules seem to cover the send path (NdisTimedDataHang) and !ndiskd.pendingnbls
with TrackNblOwner shows held NBLs, but nothing flags a chain whose tail the
miniport can no longer walk.
Happy to post the measured numbers if useful.