Regards,
Bala

On 26 February 2016 at 11:51, José Pekkarinen <jose.pekkari...@nokia.com>
wrote:

> On Thursday 25 February 2016 15:01:11 EXT Bill Fischofer wrote:
>
> > On Thu, Feb 25, 2016 at 12:39 PM, José Pekkarinen <
> jose.pekkari...@nokia.com
>
> > > wrote:
>
> > >
>
> > > On Thursday 25 February 2016 11:54:31 EXT Bill Fischofer wrote:
>
> > > > Anything with an initial underscore (like _odp_cast_scalar()) is an
>
> > > >
>
> > > > implementation-internal API (in this case, linux-generic) and is most
>
> > > >
>
> > > > definitely neither portable nor subject to any release-to-release
>
> > > >
>
> > > > compatibility guarantees, so I'd highly discourage trying to use
> them.
>
> > >
>
> > > It's used under the scope of the platform folder of odp, not outside of
>
> > > that, and just limited to this usecase, where some vendor decides that
>
> > > want
>
> > > to use unions to define types that linux-generic does with other kind
> of
>
> > > data structure.
>
> > >
>
> > > > If I understand your use case correctly, you want to create a queue
> but
>
> > > >
>
> > > > (perhaps temporarily) put it into a state where other queue
> operations
>
> > > > on
>
> > > >
>
> > > > it are rejected? We've previously talked about defining an
>
> > > >
>
> > > > odp_queue_quiesce() API that would prohibit further enqueues to a
> queue
>
> > > >
>
> > > > while still permitting existing elements to be dequeued from it.
> This to
>
> > > >
>
> > > > support graceful termination where you want to drain a queue before
>
> > > >
>
> > > > destroying it. A corresponding odp_queue_resume() call would return a
>
> > > >
>
> > > > quiesced queue to normal operation. Would such a capability suffice
> for
>
> > > >
>
> > > > your use case or are you also looking to reject dequeue and/or
> destroy
>
> > > >
>
> > > > operations on the queue while it is "invalid"? Also, wouldn't you
> need a
>
> > > >
>
> > > > odp_queue_revalidate() API to bookend odp_queue_invalidate()?
>
> > >
>
> > > The situation is the other way around. When we create an interface, the
>
> > > structure defines the queues, and it will initialize all it's data
>
> > > structure one after another, until it gets to the end of the
>
> > > initialization
>
> > > or some initialization error happens. If the queue is created
> correctly,
>
> > > but some problem in the initialization happens later on, the queue is
>
> > > cleaned up setting it to invalid until we can memset the structure.
> This
>
> > > is
>
> > > valid also when you happen to have corruption in the queue, or failures
>
> > > sending some packets through the queue(burst failures, etc).
>
> >
>
> > If your structure contains an odp_queue_t handle in it, then that
> variable
>
> > can always be set to ODP_QUEUE_INVALID, which is the designated portable
>
> > handle value to indicate an invalid queue.
>
>
>
> And this is what we want, to have more flexibility to set this to invalid,
> as the only way to do a pure assignation to ODP_QUEUE_INVALID for unions is
> setting ODP_QUEUE_INVALID as stated in the following line.
>
>
>
> #define ODP_QUEUE_INVALID _odp_cast_scalar(odp_queue_t, ~(unsigned)0)
>
>
>
> > If you have created the queue
>
> > via odp_queue_create() and received a handle for it then you at some
> point
>
> > need to do a corresponding odp_queue_destroy() queue to free up any ODP
>
> > resources associated with that queue. Simply throwing away the handle
>
> > would result in resource leakage.
>
>
>
> Sure, odp_queue_destroy should be called, but it takes more processing
> time than just setting the queue to invalid, and it can be performed when
> no demanding network load is coming.
>

If the queue is successfully create by the implementation and a valid queue
handle is returned then odp_queue_destroy() function is required to clear
any HW resources allocated by the implementation. So that handle cannot be
set to invalid by the application.

Regards,
Bala

>
>
> Best regards.
>
>
>
> José.
>
>
>
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to