You can set an odp_queue_t variable to ODP_QUEUE_INVALID as an initial
value but not as an alternative to odp_queue_destroy(). If you want to
defer the destroy operation that's fine, however you still need to remember
the handle someplace so that it can be used in a subsequent destroy call to
release the implementation resources associated with it.
As Bala notes, until these resources are released that may limit the
ability to do create() calls for other queues.
Note also, that if you want to make a reference to ODP_QUEUE_INVALID you
must do so using that designated symbol, not by reaching into whatever
implementation-specific construct may be behind that symbol. Like any
other handle, the various ODP_xxx_INVALID handles are opaque and are
designed to be used as comparators to indicate allocation/create success or
failure.
So the following sort of code is perfectly acceptable:
odp_queue_t my_q = ODP_QUEUE_INVALID; // Initialize my_q to unallocated
state
...
if (my_q == ODP_QUEUE_INVALID) // We need to create a queue
my_q = odp_queue_create(...);
...
// Destroy my_q and return it to unallocated state
if (my_q != ODP_QUEUE_INVALID) {
if (odp_queue_destroy(my_q) == 0)
my_q = ODP_QUEUE_INVALID;
else ... // destroy failed (q probably not empty), take some other
action
}
So if you want to defer queue destruction, simply note that and put the
handle on a deferred deallocation list someplace.
On Fri, Feb 26, 2016 at 2:57 AM, Bala Manoharan <[email protected]>
wrote:
>
>
> Regards,
> Bala
>
> On 26 February 2016 at 12:41, José Pekkarinen <[email protected]>
> wrote:
>
>>
>>
>> Hi,
>>
>>
>>
>> > > 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.
>>
>> >
>>
>>
>>
>> Yes, that is for sure, but does it have to be cleaned up immediately? Is
>> there no way to delay the processing of the destroy function until we are
>> not in a hurry?
>>
>
> That depends on your application since if you are delaying cleaning up a
> queue you might actually deny creating new queue as the platform might
> overruns the total amount of queue supported.
>
> Also just to be clear, odp handles are opaque to the application and it
> does not have the right to set the handle to INVALID directly. It has to go
> through the implementation to INVALIDATE a handle and currently the only
> way is to call odp_xxx_destroy() API.
>
> Regards,
> Bala
>
>>
>>
>> Best regards.
>>
>>
>>
>> José.
>>
>>
>>
>
>
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
