KMDF Driver. What are the recommended limits for buffer size when calling WdfCommonBufferCreate

Question

Hi,
I have a customer who wants to really stress-test his PCIe hardware. His idea is to declare two 8 GB buffers alternately filled by application software and fetched by scatter/gather DMA in the hardware (Transfer to PCIe card). If I calculate this through,
this is a maximum of 2M scatter/gather elements per buffer or 32 MByte, assuming S/G element is 16 bytes. i.e. 64 MByte logically contiguous memory as a common buffer for storing the S/G lists. The test system will have plenty of memory, 32 G upwards.
Still don't think I am likely to get a 64MByte common buffer from the system or even two disjunct 32 Mbyte buffers. If I look at poolmon on my server, the current size for NP is only 86M
So I expect the driver will have to handle multiple calls to EvtProgramDma, each covering just part of the 8G to be transferred.
Still I have two questions:
1) Are there any recommendations, house numbers from experience etc. regarding what is a usable maximum size I can reliably get for a common buffer with a call to WdfCommonBufferCreate (percentage of NP pool?, absolute number? ...). The common buffer is
for storing the S/G elements for the HW DMA controller
2) If I just declare a huge array of SCATTER_GATHER_ELEMENT[4M] or 2x huge arrays SCATTER_GATHER_ELEMENT[2M] in the device context (to be managed later by WdfMemoryCreatePreallocated() etc.) , will windows refuse to load the driver because the driver footprint
is too large?
We are talking about Windows 7/x64
Thanks,
Charles

Answer 1

Don,
thanks for your reply. The card is always physically present in the test system which means I could load the driver at boot time, but it would have to be after PCIe enumeration of course.
So far I have always managed to avoid writing a boot-start driver, my main objection being for "purist" reasons. I understand the MS documentation to mean that boot-start is really only intended for devices that are required to boot the system
(disk, console, keyboard, maybe network ....). I am aware of the advantage of boot-start though, a much higher probability of getting contiguous memory in larger chunks. This driver however is definitely not relevant for system start. The add-in card is essentially
a high performance source of test data and only runs when a SW application has been started.
The card does have high performance scatter/gather DMA support also 64-bit addressing capability.
I do wish Microsoft would issue some guidelines regarding realistic sizing of common buffers, it would make my discussion easier. Yes, I could write a test driver and measure it out but I don't really have time for that. Microsoft surely have test/application
teams for figuring these things out.
Charles