Goal

Currently the driver do not use the "merged buffers feature", providing for RX queue in each entry enough buffer to accomodate a packet of maximal possible size. The max packet size is approx 64K (if RSC is on), or 9K (RSC is off, regular jumbo packets) or 1.5K (RSC off, regular packets). Escecially in the out-of-the-box case (RSC on) this mean that the driver must preallocate ~17MB of shared memory for each queue (queue size 256) or ~67MB for each queue (queue size 1024). Number of queues is the parameter of specific user configuration (4 - 8 queues might be used as a ball park). So, for discussion we can assume typical numbers of 70 - 500 MB of shared memory allocation for RX.

Real usage of the memory depends on exact usage scenarion but in almost any real stress case the used memory is much lower than allocated, in most scenarios it is less than 20%, in some scenarios - even less than 5%.

Using merged buffers the shared memory consumption can be reduced approx 16 times. Activation of this feature seems to be more relevant in specific customer setups:

• with very large shared memory consumption, for example multiple RX queues of 1024 entries and RSC on. For such case we can also reduce the memory consumption at some level (using buffers between 4K and 64K), keeping the balance between performance and footprint
• with RSC off. Currently even if the RSC is disabled on the guest (by powershell script) the driver still allocates large buffers (~64K per packet) as the HCK tests may enable RSC at run it (assuming it is supported). At the same time customers will not practice run-time settings of RSC (if they turn it off, the do it intentionally). Using merged buffers we can reduce the RX memory consumption (as said ~16 times) and still pass the HCK tests. 
• failover device. Our device is backup one during the migration. Probably It does not need large buffers. 

Acceptance Criteria

TBD at the moment