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

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

[Sanford, Robert]

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?

--
Regards,
Robert

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

[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?

/Bruce

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

[Thomas Monjalon]

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.

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

[Mcnamara, John]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Sanford, Robert
> Sent: Thursday, July 2, 2015 10:05 PM
> To: Richardson, Bruce; Thomas Monjalon; dev@dpdk.org
> Subject: [dpdk-dev] Ethernet API - multiple post-RX-burst callbacks' run-
> order is opposite to their add-order
> 
> 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.

Hi,

I think you are right and that the current order of execution for callbacks is counter-intuitive.

I've submitted a patch to fix the order:

    http://dpdk.org/dev/patchwork/patch/6300/

If the patch is accepted I'll add a note to the release notes also.

John.
-- 

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

[Thomas Monjalon]

2015-07-10 13:14, Mcnamara, John:
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Sanford, Robert
> > 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.
> 
> Hi,
> 
> I think you are right and that the current order of execution for callbacks is counter-intuitive.
> 
> I've submitted a patch to fix the order:
> 
>     http://dpdk.org/dev/patchwork/patch/6300/

Thanks John.
Don't hesitate to use Suggested-by: to give credits.
 
> If the patch is accepted I'll add a note to the release notes also.

Why not doing the release notes change atomicly in the same patch?

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

[Mcnamara, John]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Friday, July 10, 2015 2:24 PM
> To: Mcnamara, John
> Cc: Sanford, Robert; Richardson, Bruce; dev@dpdk.org
> Subject: Re: Ethernet API - multiple post-RX-burst callbacks' run-order is
> opposite to their add-order

Hi Thomas,

>
> Don't hesitate to use Suggested-by: to give credits.

I wasn't aware of that. I'll use it in future.

> > If the patch is accepted I'll add a note to the release notes also.
> 
> Why not doing the release notes change atomicly in the same patch?

Mainly, because there isn't currently a clear place to do that in the release notes. I could change the "New Features" section to "New Features in 2.0" and then add a "New Features in 2.1". Or perhaps this needs to go into a "Changed Features in 2.1" section. If you have a suggestion I'll follow it.

And I support your previous suggestion of updating the release notes in patchsets. That would make things easier for the release notes maintainers (me and you mainly).

Perhaps I'll kick off a separate thread of discussion on refactoring the release notes to make them more useful and easier to update.

John.
-- 
 

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

[Thomas Monjalon]

2015-07-10 13:52, Mcnamara, John:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > If the patch is accepted I'll add a note to the release notes also.
> > 
> > Why not doing the release notes change atomicly in the same patch?
> 
> Mainly, because there isn't currently a clear place to do that in the
> release notes. I could change the "New Features" section to "New Features
> in 2.0" and then add a "New Features in 2.1". Or perhaps this needs to go
> into a "Changed Features in 2.1" section. If you have a suggestion I'll
> follow it.

I think we should reset "new features" at the beginning of the release cycle.
Maybe that the "supported features" section needs a refresh also.

> And I support your previous suggestion of updating the release notes
> in patchsets. That would make things easier for the release notes
> maintainers (me and you mainly).

You mean asking to every developers to update the release notes?
Just to be sure we are on the same line.

> Perhaps I'll kick off a separate thread of discussion on refactoring
> the release notes to make them more useful and easier to update.

OK thanks