Thanks for raising this point. As in all things ODP, we need to distinguish carefully between what the APIs define and how individual implementations may realize these APIs. Applications looking to be portable across ODP implementations need to be careful to not make assumptions about how APIs are implemented and instead stick to the behaviors as specified.
For the various abstract types (odp_buffer_t, odp_buffer_pool_t, odp_packet_t, odp_queue_t, etc.) the assumption is that the implementation defines what's behind them and the application simply uses them as handles in referring to instances of these objects. The scope of these handles is a single ODP application. So if an application receives an odp_buffer_t it can assume that that handle refers to the same buffer in that application for the life of that buffer. If an application puts a buffer on a queue via a call like odp_queue_enq(q,buf); and some other part of the application then retrieves it via an odp_queue_deq() or odp_schedule() call, ODP itself does not specify whether the handle has the same value, because values are not part of the ODP APIs for handles other than specific designated values like ODP_BUFFER_INVALID, etc. For most implementations one would assume this is likely, however it's not something the application would depend on since it's simply using the handle it's given by the API. If an application wished to pass a buffer handler around using some private mechanism then it is free to do so, but in theory implementations can transform handles across ODP API boundaries. What an application cannot do is send a handle to some external entity (including another ODP application) and expect the recipient to be able to do anything useful with it. Bill On Tue, Oct 21, 2014 at 11:25 AM, Gilad Ben Yossef <[email protected]> wrote: > > > 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: [email protected], Web: http://www.ezchip.com > > "Ethernet always wins." > — Andy Bechtolsheim > > > > -----Original Message----- > > From: [email protected] [mailto:lng-odp- > > [email protected]] On Behalf Of Maxim Uvarov > > Sent: Tuesday, October 21, 2014 6:28 PM > > To: [email protected] > > Subject: Re: [lng-odp] Questions about odp_buffer_t > > > > On 10/21/2014 06:52 PM, Gilad Ben Yossef wrote: > > > > > > Quick question – > > > > > > What are the assumptions about an odp_buffer_t ? > > > > > > For example - > > > > > > Can an application assume the odp_buffer_t is always the same for the > > > same buffer? I would assume no. > > > > > > > For current linux-generic implementation it's so. For other I think it's > > the same. odp_buffer_t is offset in pool, which always points to the > > same memory. > [gby] My understanding was that odp_buffer_t is an opaque handle to a > buffer and offset in a pool is a specific implementation of linux-generic. > Just as an example - > Armv8 has a notion of "tagged pointers". If I want an Armv8 based SoC to > use tagged pointers to be used as odp_buffer_t and the tag part of the > pointer is, say, which queue the buffer came from so I can track it for > prvided ORDERED and ATOMIC queues support, the result is that two different > odp_buffer_t may point to the same buffer. > My platform doesn't happen to be Armv8, I just used it as an example for > what a specific SoC can do if you allow odp_buffer_t to be opaque. > > > > > Can an application assume the odp_buffer_t is globally unique? I would > > > assume no. > > > > > > > yes, why no? again in linux-generic odp_buffer_t is coded by bits > > <pool_id, index offset>, so it's point to exact memory address. Soc use > > the same thing I think. > [gby] Again, I understand this is the *implementation* of linux-generic. > Again, different SoC platform may have many reason to do something else. > For example - if I have a hardware queue mechanism my odp_buffer_t may > mean on my platform "position X in the incoming work scheduling queue for > this thread" - and I have data structure in a ring in memory that tell me > where to find the buffer. > It means that two different threads will see two different buffers at the > same numeric value of odp_buffer_t. > But again, it's a completely valid way for a platform to handle buffers if > it wants ORDERED queues > > > > > Can an application assume the odp_buffer_t it may be passed via shared > > > memory and be expected keep its meaning? I would assume no. > > > > > > > That depends. If it's transfered in the same process then it will be > > same odp_buffer_t. If it's separate process and shared memory between > > them then to have the same odp_buffer_t you need to have the same table > > for pool entries. I.e. if you do fork() after odp_global_init() it will > > be the same. If it's completely 2 separate process and shared memory > > between them, than ... it's possible to do that, but definitely not > > implemented now. > [gby] Again, if my odp_buffer_t is a tagged Armv8 pointer with the tag > bits pointing to an index in a thread local array where I store status bits > (e.g. which queue I came from...) than if I put an odp_buffer_t in a shared > memory and expect to grab the odp_buffer_t from some other thread and that > it will be valid it won't work. > > Which brings me back to my original question - what can application assume > about an odp_buffer_t and what it cannot assume? > Surely we don't expect all SoC and platforms to implement odp_buffer_t as > bits coding a pool and an index. > What are the rules a platform must obey? > Personally, I'd be very happy if the rules says odp_buffer_t is an opaque > handle and you can't assume anything about it (think Linux file descriptor) > but obviously this needs some discussion. > Gilad > > > > Maxim. > > > > > Anyone has any thought about this? > > > > > > Thanks, > > > > > > 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: [email protected] <mailto:[email protected]>, Web: > > > http://www.ezchip.com <http://www.ezchip.com/> > > > > > > // > > > > > > /"Ethernet always wins."/ > > > > > > — Andy Bechtolsheim// > > > > > > > > > > > > _______________________________________________ > > > lng-odp mailing list > > > [email protected] > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > _______________________________________________ > > lng-odp mailing list > > [email protected] > > http://lists.linaro.org/mailman/listinfo/lng-odp > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
