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
