<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word"> <div class="WordSection1"> Hi, <o:p> </o:p> I’ve tracked down a regression in SPDK to DPDK commit a2833ecc5 (“mempool: fix get objects from mempool with cache”). <o:p> </o:p> Here’s an example that demonstrates the problem: <o:p> </o:p> Allocate mempool with 2048 buffers and cache size 256. Core 0 allocates 512 buffers. Mempool pulls 512 + 256 buffers from backing ring, returns 512 of them to caller, puts the other 256 in core 0 cache. Backing ring now has 1280 buffers. Core 1 allocates 512 buffers. Mempool pulls 512 + 256 buffers from backing ring, returns 512 of them to caller, puts the other 256 in core 1 cache. Backing ring now has 512 buffers. Core 2 allocates 512 buffers. Mempool pulls remaining 512 buffers from backing ring and returns all of them to caller. Backing ring now has 0 buffers. Core 3 tries to allocate 512 buffers and it fails. <o:p> </o:p> In the SPDK case, we don’t really need or use the mempool cache in this case, so changing the cache size to 0 fixes the problem and is what we’re going to move forward with. But the behavior did cause a regression so I thought I’d mention it here. If you have a mempool with 2048 objects, shouldn’t 4 cores each be able to do a 512 buffer bulk get, regardless of the configured cache size? <o:p> </o:p> Regards, <o:p> </o:p> Jim Harris <o:p> </o:p> <o:p> </o:p> </div> </body> </html>