From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============4761492517661541732==" MIME-Version: 1.0 From: Harris, James R Subject: Re: [SPDK] SPDK NVMe CMB WDS/RDS Support: Thanks and next steps! Date: Thu, 15 Feb 2018 21:15:17 +0000 Message-ID: <21421AB2-A85B-4564-AB9D-E9CB0F478DB0@intel.com> In-Reply-To: 41EA3D38-F61B-442A-B09F-D8A1DACCEE5E@raithlin.com List-ID: To: spdk@lists.01.org --===============4761492517661541732== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 2/15/18, 2:02 PM, "Stephen Bates" wrote: Jim = > We also need a better CMB allocation scheme. = = Ha! I knew there was a feature I was forgetting. This is it. Yes for su= re, thanks for reminding me. I have added it to my list so I don't forget n= ext time. = = Do we have anything like this in SPDK already or does anyone have any poi= nters to a licence compatible open-source allocator that might suit our nee= ds? There=E2=80=99s really nothing like this today in SPDK. I believe DPDK pro= vides a way to use their allocators with =E2=80=9Cuser-provided=E2=80=9D me= mory =E2=80=93 i.e. not from the hugepages allocated in host memory by DPDK= . But I haven=E2=80=99t looked at exactly how that works. I guess I=E2=80=99m not 100% sold that we need a full-blown allocator. May= be what we have currently is enough =E2=80=93 the user can allocate the mem= ory but it=E2=80=99s up to the user how it is managed. Meaning that the fr= ee_cmb_io_buffer routine effectively goes away. And just be explicit in th= e API =E2=80=93 i.e. here=E2=80=99s the call you make to get the CMB buffer= and its size =E2=80=93 what you choose to do with it is your business. We= could always provide some kind of allocator later =E2=80=93 but that can b= e done outside of the SPDK NVMe CMB logic itself. I=E2=80=99m curious =E2=80=93 how much CMB does one of your NoLoad card hav= e? -Jim --===============4761492517661541732==--