I'd add to this if the reason for using a non-ODP API is that the equivalent ODP API is missing something we'd like to know about that so that may be corrected in a future revision of the API. Over time I'd expect the ODP APIs to gain richness both as the framework matures and as it tracks the increasing capabilities of the platforms that support it.
On Tue, Nov 4, 2014 at 3:24 AM, Gilad Ben Yossef <gil...@ezchip.com> wrote: > > > I think it's fair to note though that applications that uses any API > outside ODP may not be portable across other ODP platforms, or even exhibit > different performance characteristic from ODP APIs on the same platform. > > > > Therefore I expect that **all other things being equal**, there is an > advantage for the application writer to use ODP APIs where applicable APIs > exists. > > > > If you're faced with an already existing hunk of code, that probably > doesn't matter at all. If you're writing a new application and you are > targeting ODP anyway, I would find it weird if you'd use a none ODP API for > something ODP has an API for unless the ODP API semantic is somehow missing > something. > > > > Gilad > > > > > > > > > > > > > > *Gilad Ben-Yossef* > > Software Architect > > EZchip Technologies Ltd. > > 37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel > > Tel: +972-4-959-6666 ext. 576, Fax: +972-8-681-1483 > Mobile: +972-52-826-0388, US Mobile: +1-973-826-0388 > > Email: gil...@ezchip.com, Web: http://www.ezchip.com > > > > *"Ethernet always wins."* > > — Andy Bechtolsheim > > > > *From:* lng-odp-boun...@lists.linaro.org [mailto: > lng-odp-boun...@lists.linaro.org] *On Behalf Of *Bill Fischofer > *Sent:* Monday, November 03, 2014 8:11 PM > *To:* Shmulik Ladkani > *Cc:* lng-odp@lists.linaro.org > *Subject:* Re: [lng-odp] [Q] Memory allocation in ODP applications > > > > 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
