On Thu, Feb 25, 2016 at 12:39 PM, José Pekkarinen <[email protected] > 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. 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. So in the use case you describe, it sounds like you've done the odp_queue_create() and some subsequent initialization step fails and you want to back out the changes. In that case why isn't odp_queue_destroy() sufficient? After the odp_queue_destroy() call you can set the struct's handle value to ODP_QUEUE_INVALID to indicate that the queue is invalid. > > 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
