ODP APIs are divided into two classes: Mandatory, which all conforming ODP implementations are expected to provide, and Optional. The convention is that Optional APIs must be present but calling them may simply result in an ODP_FUNCTION_NOT_AVAILABLE return code. These are documented in the associated header files (currently under revision) and are part of the doxygen. Basically, unless an API calls itself out as OPTIONAL you should assume that all ODP implementations will provide functional implementations of it, though performance of individual APIs may vary between platforms and within platforms over time.
It's expected that each platform will provide implementations of the ODP APIs that are optimized for that particular platform. ODP itself does not specify how implementations do that or how they might improve performance over time with subsequent releases of the implementation. This was the reason for decoupling the APIs from the implementations and supporting multiple repositories. It's expected that, over time, implementations will evolve and improve their performance as the implementations become better tuned to refinements in their underlying platform. Hope that helps. Bill On Mon, Nov 3, 2014 at 2:18 PM, Shmulik Ladkani <shmulik.ladk...@gmail.com> wrote: > On Mon, 3 Nov 2014 12:11:26 -0600 Bill Fischofer < > bill.fischo...@linaro.org> wrote: > > 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. > > Thanks Bill. > > This leads me to few additional questions: > > Are all memory-related ODP APIs mandatory (must be implemented by the > platform)? > > Are they required to provide any other benefit over standard (or custom) > allocation routines besides the portability guarantee? > > Regards, > Shmulik >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
