Re: [dpdk-dev] Ethernet API - multiple post-RX-burst callbacks' run-order is opposite to their add-order

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2015-07-03 10:57, Bruce Richardson:
> On Thu, Jul 02, 2015 at 09:04:48PM +0000, Sanford, Robert wrote:
> > When one adds multiple post-RX-burst callbacks to a queue, their execution order is the opposite of the order in which they are added. For example, we add callback A( ), and then we add callback B( ). When we call rte_eth_rx_burst, after invoking the device's rx_pkt_burst function, it will invoke B( ), and then A( ). The same goes for pre-TX-burst callbacks, too.
> > 
> > This is counter-intuitive. Shouldn't we either execute the callbacks in the same order that we add them (by changing the internals of the add-APIs), or change the add-APIs to allow one to specify whether a callback is added to the head or tail of the callback list? At the least, we could document the expected behavior.
> > Any thoughts on this?
> > 
> Makes sense. I would agree that having the callbacks called in order of addition
> makes more sense. 
> Having the order configurable might be useful, but would require an API change,
> so I'd only look to change that if it really proves necessary. If the callback
> order is consistent and behaves logically (i.e. order of call == order of add),
> can the app not ensure the callbacks are added in the correct order?

+1 to improve behaviour without changing the API.
If the applications can manage with a simple DPDK API, it's better for everyone.