On Thu, Nov 24, 2016 at 07:29:13AM +0530, Jerin Jacob wrote: > On Wed, Nov 23, 2016 at 07:39:09PM +0100, Thomas Monjalon wrote:
Just some comments on mine triggered by Thomas comments? <snip> > > + */ > > > +static inline int > > > +rte_event_enqueue(uint8_t dev_id, uint8_t port_id, struct rte_event *ev) > > > > Is it really needed to have non-burst variant of enqueue/dequeue? > > Yes. certain HW can work only with non burst variants. In those cases is it not acceptable just to have the dequeue_burst function return 1 all the time? It would allow apps to be more portable between burst and non-burst varients would it not. > > > > > +/** > > > + * Converts nanoseconds to *wait* value for rte_event_dequeue() > > > + * > > > + * If the device is configured with RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT > > > flag then > > > + * application can use this function to convert wait value in > > > nanoseconds to > > > + * implementations specific wait value supplied in rte_event_dequeue() > > > > Why is it implementation-specific? > > Why this conversion is not internal in the driver? > > This is for performance optimization, otherwise in drivers > need to convert ns to ticks in "fast path" > > > Is that really likely to be a performance bottleneck. I would expect modern cores to fly through basic arithmetic in a negligable amount of cycles? /Bruce
