ODP APIs are designed to be used *a la carte* by applications, as ODP is a framework, not a platform. So feel free to mix malloc() or your own memory management or other API calls in as needed.
What ODP requires is the types specified in its APIs, so for example the only way to get an odp_buffer_t is via the odp_buffer_alloc() call. odp_buffer_alloc() in turn requires an odp_buffer_pool_t and that in turn requires an odp_buffer_pool_create() call. ODP_BUFFER_TYPE_RAW simply exposes the basic block manager functions of the ODP buffer APIs. Again, you're free to use them for whatever purpose the application wants. Obviously one reason for doing so is to gain portability across potentially different memory management implementations. On Mon, Nov 3, 2014 at 11:02 AM, Shmulik Ladkani <shmulik.ladk...@gmail.com> wrote: > Hi, > > As demonstrated by odp/examples, libc memory allocation routines (malloc > and friends) aren't been used by ODP apps (unless for a very tight > temporary scope, usually in the control thread). > > Application's data structures are allocated either using odp_buffer_pool > interface (e.g. odp_ipsec.c allocating its private per packet context > structure using a ODP_BUFFER_TYPE_RAW pool), or directly using > odp_shm_reserve and managing it internally (e.g. odp_ipsec_fwd_db.c, > odp_ipsec_sp_db.c etc). > > Questions: > > Must the application use ODP memory allocation interfaces at all times? > Or only for data structures accessed at data-path routines? > Or only when allocating them from within data-path routines? > > Any preference for when to use a ODP_BUFFER_TYPE_RAW pool vs. allocating > a shared memory and managing data structures internally? > > Thanks, > Shmulik > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
