From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sanford, Robert" Subject: Ethernet API - multiple post-RX-burst callbacks' run-order is opposite to their add-order Date: Thu, 2 Jul 2015 21:04:48 +0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To: "Richardson, Bruce" , Thomas Monjalon , "dev@dpdk.org" Return-path: Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by dpdk.org (Postfix) with ESMTP id 4F31C11F5 for ; Thu, 2 Jul 2015 23:04:51 +0200 (CEST) Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "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), o= r change the add-APIs to allow one to specify whether a callback is added t= o the head or tail of the callback list? At the least, we could document th= e expected behavior. Any thoughts on this? -- Regards, Robert