On Wed, Oct 26, 2016 at 01:54:14PM +0100, Bruce Richardson wrote: > On Wed, Oct 26, 2016 at 05:54:17PM +0530, Jerin Jacob wrote: > > On Wed, Oct 26, 2016 at 12:11:03PM +0000, Van Haaren, Harry wrote: > > > > -----Original Message----- > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jerin Jacob > Thanks. One other suggestion is that it might be useful to provide > support for having typed queues explicitly in the API. Right now, when > you create an queue, the queue_conf structure takes as parameters how > many atomic flows that are needed for the queue, or how many reorder > slots need to be reserved for it. This implicitly hints at the type of > traffic which will be sent to the queue, but I'm wondering if it's > better to make it explicit. There are certain optimisations that can be > looked at if we know that a queue only handles packets of a particular > type. [Not having to handle reordering when pulling events from a core > can be a big win for software!].
If it helps in SW implementation, then I think we can add this in queue configuration. > > How about adding: "allowed_event_types" as a field to > rte_event_queue_conf, with possible values: > * atomic > * ordered > * parallel > * mixed - allowing all 3 types. I think allowing 2 of three types might > make things too complicated. > > An open question would then be how to behave when the queue type and > requested event type conflict. We can either throw an error, or just > ignore the event type and always treat enqueued events as being of the > queue type. I prefer the latter, because it's faster not having to > error-check, and it pushes the responsibility on the app to know what > it's doing. How about making default as "mixed" and let application configures what is not required?. That way application responsibility is clear. something similar to ETH_TXQ_FLAGS_NOMULTSEGS, ETH_TXQ_FLAGS_NOREFCOUNT with default. /Jerin > > /Bruce