DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] Ethernet API - multiple post-RX-burst callbacks' run-order is opposite to their add-order
@ 2015-07-02 21:04 Sanford, Robert
  2015-07-03  9:57 ` Bruce Richardson
  2015-07-10 13:14 ` Mcnamara, John
  0 siblings, 2 replies; 7+ messages in thread
From: Sanford, Robert @ 2015-07-02 21:04 UTC (permalink / raw)
  To: Richardson, Bruce, Thomas Monjalon, dev

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [dpdk-dev] Ethernet API - multiple post-RX-burst callbacks' run-order is opposite to their add-order
  2015-07-02 21:04 [dpdk-dev] Ethernet API - multiple post-RX-burst callbacks' run-order is opposite to their add-order Sanford, Robert
@ 2015-07-03  9:57 ` Bruce Richardson
  2015-07-03 10:02   ` Thomas Monjalon
  2015-07-10 13:14 ` Mcnamara, John
  1 sibling, 1 reply; 7+ messages in thread
From: Bruce Richardson @ 2015-07-03  9:57 UTC (permalink / raw)
  To: Sanford, Robert; +Cc: dev

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [dpdk-dev] Ethernet API - multiple post-RX-burst callbacks' run-order is opposite to their add-order
  2015-07-03  9:57 ` Bruce Richardson
@ 2015-07-03 10:02   ` Thomas Monjalon
  0 siblings, 0 replies; 7+ messages in thread
From: Thomas Monjalon @ 2015-07-03 10:02 UTC (permalink / raw)
  To: Bruce Richardson, Sanford, Robert; +Cc: dev

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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [dpdk-dev] Ethernet API - multiple post-RX-burst callbacks' run-order is opposite to their add-order
  2015-07-02 21:04 [dpdk-dev] Ethernet API - multiple post-RX-burst callbacks' run-order is opposite to their add-order Sanford, Robert
  2015-07-03  9:57 ` Bruce Richardson
@ 2015-07-10 13:14 ` Mcnamara, John
  2015-07-10 13:24   ` Thomas Monjalon
  1 sibling, 1 reply; 7+ messages in thread
From: Mcnamara, John @ 2015-07-10 13:14 UTC (permalink / raw)
  To: Sanford, Robert, Richardson, Bruce, Thomas Monjalon, dev

> -----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.
-- 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [dpdk-dev] Ethernet API - multiple post-RX-burst callbacks' run-order is opposite to their add-order
  2015-07-10 13:14 ` Mcnamara, John
@ 2015-07-10 13:24   ` Thomas Monjalon
  2015-07-10 13:52     ` Mcnamara, John
  0 siblings, 1 reply; 7+ messages in thread
From: Thomas Monjalon @ 2015-07-10 13:24 UTC (permalink / raw)
  To: Mcnamara, John; +Cc: dev

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?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [dpdk-dev] Ethernet API - multiple post-RX-burst callbacks' run-order is opposite to their add-order
  2015-07-10 13:24   ` Thomas Monjalon
@ 2015-07-10 13:52     ` Mcnamara, John
  2015-07-10 14:02       ` Thomas Monjalon
  0 siblings, 1 reply; 7+ messages in thread
From: Mcnamara, John @ 2015-07-10 13:52 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: dev

> -----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.
-- 
 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [dpdk-dev] Ethernet API - multiple post-RX-burst callbacks' run-order is opposite to their add-order
  2015-07-10 13:52     ` Mcnamara, John
@ 2015-07-10 14:02       ` Thomas Monjalon
  0 siblings, 0 replies; 7+ messages in thread
From: Thomas Monjalon @ 2015-07-10 14:02 UTC (permalink / raw)
  To: Mcnamara, John; +Cc: dev

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2015-07-10 14:03 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-02 21:04 [dpdk-dev] Ethernet API - multiple post-RX-burst callbacks' run-order is opposite to their add-order Sanford, Robert
2015-07-03  9:57 ` Bruce Richardson
2015-07-03 10:02   ` Thomas Monjalon
2015-07-10 13:14 ` Mcnamara, John
2015-07-10 13:24   ` Thomas Monjalon
2015-07-10 13:52     ` Mcnamara, John
2015-07-10 14:02       ` Thomas Monjalon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).