On Wed, 25 Jan 2017 17:29:18 +0000, "Ananyev, Konstantin" <konstantin.anan...@intel.com> wrote: > > > > Bonus question: > > > > * Do we know how widely used the enq_bulk/deq_bulk functions > > > > are? They are useful for unit tests, so they do have uses, but > > > > I think it would be good if we harmonized the return values > > > > between bulk and burst functions. Right now: > > > > enq_bulk - only enqueues all elements or none. Returns 0 > > > > for all, or negative error for none. > > > > enq_burst - enqueues as many elements as possible. Returns > > > > the number enqueued. > > > > > > I do use the apis in pktgen and the difference in return values > > > has got me once. Making them common would be great, but the > > > problem is > > backward compat to old versions I would need to have an ifdef in > > pktgen now. So it seems like we moved the problem to the > > application. > > > > > > > Yes, an ifdef would be needed, but how many versions of DPDK back > > do you support? Could the ifdef be removed again after say, 6 > > months? > > > I would like to see the old API kept and a new API with the new > > > behavior. I know it adds another API but one of the API would be > > > nothing > > more than wrapper function if not a macro. > > > > > > Would that be more reasonable then changing the ABI? > > > > Technically, this would be an API rather than ABI change, since the > > functions are inlined in the code. However, it's not the only API > > change I'm looking to make here - I'd like to have all the > > functions start returning details of the state of the ring, rather > > than have the watermarks facility. If we add all new functions for > > this and keep the old ones around, we are just increasing our > > maintenance burden. > > > > I'd like other opinions here. Do we see increasing the API surface > > as the best solution, or are we ok to change the APIs of a key > > library like the rings one? > > I am ok with changing API to make both _bulk and _burst return the > same thing. Konstantin
I agree that the _bulk() functions returning 0 or -err can be confusing. But it has at least one advantage: it explicitly shows that if user ask for N enqueues/dequeues, it will either get N or 0, not something between. Changing the API of the existing _bulk() functions looks a bit dangerous to me. There's probably a lot of code relying on the ring API, and changing its behavior may break it. I'd prefer to deprecate the old _bulk and _burst functions, and introduce a new api, maybe something like: rte_ring_generic_dequeue(ring, objs, n, behavior, flags) -> return nb_objs or -err Olivier
