DPC Watchdog Ticks

NTDEV
1

Hi

I wanted to try out usefulness of KeQueryDpcWatchdogInformation to have one more exit criteria from my DPC (scheduled from ISR)

typedef struct _KDPC_WATCHDOG_INFORMATION {
  ULONG DpcTimeLimit;
  ULONG DpcTimeCount;
  ULONG DpcWatchdogLimit;
  ULONG DpcWatchdogCount;
  ULONG Reserved;
} KDPC_WATCHDOG_INFORMATION, *PKDPC_WATCHDOG_INFORMATION;

Most of the time I am the first DPC, so I see all the quota 1280/7680. (DpcTimeCount/DpcWatchdogCount)
Occasionally I am not first DPC, hence like 1280/7675.

I have an exit condition from DPC based on #packets processed so far, but hypothetically even that could fail any time (like by the time my DPC scheduled, most of DpcWatchdogLimit ticks burnt by previous DPCs’ etc.), I thought I will exit early based on DpcTimeCount/DpcWatchdogCount ticks as well. But once in in my DPC, I never see these ticks being updated.
In the runs I observed I was in DPC for 1150us, 600us etc. (these times deduced based on KeQueryPerformanceCounter(NULL)) , but the ticks never got updated.
PS: KeQueryPerformanceCounter(&Freq) returns 100’000’000 for me.

Not sure if ticks get updated only before a new DPC is picked to run? Are these ticks supposed/not to get updated inside a DPC?.
Also I guess these ticks get updated based on QPC/like mechanism not based on OS tick.

MSDN suggest 100us for DPC, not sure, if I will have any throughput with that.
What would be a good quantum to bail out of DPC,. are above 1150us, 600us o.k. (assuming my elapsed time calc using QPC above is correct. Yes it could include interrupt time, but hopefully averages out over the runs).?

Seems only/fool-proof-for-ever solution (since very few ticks can be left even to do a little bit of processing before hitting #pkts threshold to exit DPC), is to schedule a workitem always.
But with workitem I won’t get any desired perf (don’t have much offloads). So I need to do some (ideally as much as possible but within the available DpcTimeLimit) processing at DPC, but want to have as many guards as possible to not ever hit BSOD 0x133 (0 or 1) .

Thanks