From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 9C81EB4ED for ; Fri, 13 Feb 2015 18:50:44 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP; 13 Feb 2015 09:44:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,572,1418112000"; d="scan'208";a="651854888" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.220.85]) by orsmga001.jf.intel.com with SMTP; 13 Feb 2015 09:49:14 -0800 Received: by (sSMTP sendmail emulation); Fri, 13 Feb 2015 17:49:12 +0025 Date: Fri, 13 Feb 2015 17:49:12 +0000 From: Bruce Richardson To: Thomas Monjalon Message-ID: <20150213174912.GA13940@bricha3-MOBL3> References: <1419266844-4848-1-git-send-email-bruce.richardson@intel.com> <1423841989-9090-1-git-send-email-john.mcnamara@intel.com> <1423841989-9090-3-git-send-email-john.mcnamara@intel.com> <1455252.yJnfHs6f2Q@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1455252.yJnfHs6f2Q@xps13> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 2/4] ethdev: Add in data rxtx callback support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 17:50:45 -0000 On Fri, Feb 13, 2015 at 05:33:12PM +0100, Thomas Monjalon wrote: > 2015-02-13 15:39, John McNamara: > > From: Richardson, Bruce > > > > Add in support for inline processing of packets inside the RX or > > TX call. For an RX callback, what happens is that we get a set of > > packets from the NIC and then pass them to a callback function, if > > configured, to allow additional processing to be done on them, e.g. > > filling in more mbuf fields, before passing back to the application. > > On TX, the packets are similarly post-processed before being handed > > to the NIC for transmission. > > > > Signed-off-by: Bruce Richardson > [...] > > @@ -2390,7 +2445,17 @@ rte_eth_rx_burst(uint8_t port_id, uint16_t queue_id, > > struct rte_eth_dev *dev; > > > > dev = &rte_eth_devices[port_id]; > > - return (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id], rx_pkts, nb_pkts); > > + nb_pkts = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id], rx_pkts, > > + nb_pkts); > > + struct rte_eth_rxtx_callback *cb = dev->rx_cbs[queue_id]; > > + if (unlikely(cb != NULL)) { > > + do { > > + nb_pkts = cb->fn(port_id, queue_id, rx_pkts, nb_pkts, > > + cb->param); > > + cb = cb->next; > > + } while (cb != NULL); > > + } > > + return nb_pkts; > > } > > #endif > > > > @@ -2517,6 +2582,14 @@ rte_eth_tx_burst(uint8_t port_id, uint16_t queue_id, > > struct rte_eth_dev *dev; > > > > dev = &rte_eth_devices[port_id]; > > + struct rte_eth_rxtx_callback *cb = dev->tx_cbs[queue_id]; > > + if (unlikely(cb != NULL)) { > > + do { > > + nb_pkts = cb->fn(port_id, queue_id, tx_pkts, nb_pkts, > > + cb->param); > > + cb = cb->next; > > + } while (cb != NULL); > > + } > > return (*dev->tx_pkt_burst)(dev->data->tx_queues[queue_id], tx_pkts, nb_pkts); > > } > > #endif > > We all know how much the performance of these functions are important. > So I wonder if we could reduce the impact of this change. > I don't like the build options but maybe it should be discussed. Performance impact is minimal, there was some discussion of it previously when I published the earlier RFC draft. In my quick tests, with vector PMD in the fast path, the impact is <=1% for this change as is (i.e. no callbacks set up), and a further 1% perf hit to actually call an empty callback. http://article.gmane.org/gmane.comp.networking.dpdk.devel/10489 http://article.gmane.org/gmane.comp.networking.dpdk.devel/10735 Unless people start seeing a higher perf hit on some platforms, I don't think a build-time option is worth having. Regards, /Bruce