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).
odp_queue_quiesce() seems to be a good idea for the
initialization, meanwhile the interface structure is created and it's data
structures are not ready, but it doesn't prevent the user from resuming it
wrongly.
odp_queue_revalidate, for our usecase, it's pretty much
useless. If the queue had some problem, the packets on it are consider
garbage and dropped. A new queue can replace the elder, and we start
feeding it with new packets.
BR.
José
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp