From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============8865356871982945362=="
MIME-Version: 1.0
From: Walker, Benjamin <benjamin.walker at intel.com>
Subject: Re: [SPDK] OS memory allocation
Date: Thu, 12 Jul 2018 17:41:06 +0000
Message-ID: <e4d5e80199efa920a066f1d860a01d1179684260.camel@intel.com>
In-Reply-To: 7B8F29A0FFD5CC41B50CD1DC0E1DA24528F93EBF@MX206CL02.corp.emc.com
List-ID: <spdk@lists.01.org>
To: spdk@lists.01.org

--===============8865356871982945362==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Hi Leonid,

On Thu, 2018-07-12 at 07:10 +0000, Ravich, Leonid wrote:
> Looks like SPDK uses OS dynamic memory  (malloc, zalloc ...) I am not
> understand why , =

> It can use spdk_malloc/ spdk_zmalloc instead and be more "system friendly=
" . =

> =

> If there is some good reason for such behavior I would like to suggest
> wrapping all the "raw"  linux system calls used by SPDK .
> =

> This way SPDK will be more flexible in different systems integrations .


SPDK very intentionally depends on the POSIX API for a large number of
operations. We've chosen to go this direction because SPDK is intended to r=
un as
regular a user space application and we want developers to be able to use a=
ll of
the regular tools available in that environment. We're concerned that not
allowing the use of POSIX APIs makes it much more difficult for people to j=
ump
in and contribute to the code, and also that it would be quite difficult to
enforce in practice. Note that this is also the choice that DPDK has made.

We have taken some steps to support more exotic environments though. First,=
 all
POSIX include files are only included via include/spdk/stdinc.h, and we act=
ually
have tests to verify that this is the case. If you have a non-POSIX environ=
ment,
you can swap out that header to include other implementations and map them =
to
the POSIX calls we make.

SPDK also requires a number of operations that are outside of the purview of
POSIX. These are all encapsulated by include/spdk/env.h. The implementation=
 of
that header is in lib/env_dpdk, and by default uses DPDK to implement all of
those operations. However, this portion is designed to be swapped out. You =
can
point SPDK at a different implementation of include/spdk/env.h through the
configuration script:

./configure --with-env=3D/path/to/your/lib.a

We further have a number of abstractions coming for threading that aren't q=
uite
done yet. SPDK is designed around cooperative multi-tasking and many locati=
ons
in the code need to be able to send messages to other threads. However, SPDK
doesn't want to force users into a particular green thread/cooperative
multitasking/futures+promises framework. We're currently designing abstract=
ions
for "light weight" threads (without an associated implementation) that users
should be able to map trivially to their particular framework.

I hope that helps clear things up. It's all about making SPDK as flexible as
possible for as many people as we can, but also making the "simple" case as=
 easy
to program and use as possible.

Thanks,
Ben
--===============8865356871982945362==--