From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 03669B5E5 for ; Mon, 16 Feb 2015 16:16:51 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 16 Feb 2015 07:16:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,588,1418112000"; d="scan'208";a="678680572" Received: from bricha3-mobl3.ger.corp.intel.com ([10.243.20.26]) by fmsmga002.fm.intel.com with SMTP; 16 Feb 2015 07:16:23 -0800 Received: by (sSMTP sendmail emulation); Mon, 16 Feb 2015 15:16:23 +0025 Date: Mon, 16 Feb 2015 15:16:23 +0000 From: Bruce Richardson To: Olivier MATZ Message-ID: <20150216151622.GA1888@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-4-git-send-email-john.mcnamara@intel.com> <54E1FFC4.1060605@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E1FFC4.1060605@6wind.com> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 3/4] examples: example showing use of callbacks. 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: Mon, 16 Feb 2015 15:16:52 -0000 On Mon, Feb 16, 2015 at 03:33:40PM +0100, Olivier MATZ wrote: > Hi John, > > On 02/13/2015 04:39 PM, John McNamara wrote: > > From: Richardson, Bruce > > > > Example showing how callbacks can be used to insert a timestamp > > into each packet on RX. On TX the timestamp is used to calculate > > the packet latency through the app, in cycles. > > > > Signed-off-by: Bruce Richardson > > > I'm looking at the example and I don't understand what is the advantage > of having callbacks in ethdev layer, knowing that the application can > do the same job by a standard function call. > > What is the advantage of having callbacks compared to: > > > for (port = 0; port < nb_ports; port++) { > struct rte_mbuf *bufs[BURST_SIZE]; > const uint16_t nb_rx = rte_eth_rx_burst(port, 0, > bufs, BURST_SIZE); > if (unlikely(nb_rx == 0)) > continue; > add_timestamp(bufs, nb_rx); > > const uint16_t nb_tx = rte_eth_tx_burst(port ^ 1, 0, > bufs, nb_rx); > calc_latency(bufs, nb_tx); > > if (unlikely(nb_tx < nb_rx)) { > uint16_t buf; > for (buf = nb_tx; buf < nb_rx; buf++) > rte_pktmbuf_free(bufs[buf]); > } > } > > > To me, doing like the code above has several advantages: > > - code is more readable: the callback is explicitly invoked, so there is > no risk to forget it > - code is faster: the functions calls can be inlined by the compiler > - easier to handle error cases in the callback function as the error > code is accessible to the application > - there is no need to add code in ethdev api to do this > - if the application does not want to use callbacks (I suppose most > applications), it won't have any performance impact > > Regards, > Olivier In this specific instance, given that the application does little else, there is no real advantage to using the callbacks - it's just to have a simple example of how they can be used. Where callbacks are really designed to be useful, is for extending or augmenting hardware capabilities. Taking the example of sequence numbers - to use the most trivial example - an application could be written to take advantage of sequence numbers written to packets by the hardware which received them. However, if such an application was to be used with a NIC which does not provide sequence numbering capability, for example, anything using ixgbe driver, the application writer has two choices - either modify his application code to check each packet for a sequence number in the data path, and add it there post-rx, or alternatively, to check the NIC capabilities at initialization time, and add a callback there at initialization, if the hardware does not support it. In the latter case, the main packet processing body of the application can be written as though hardware always has sequence numbering capability, safe in the knowledge that any hardware not supporting it will be back-filled by a software fallback at initialization-time. By the same token, we could also look to extend hardware capabilities. For different filtering or hashing capabilities, there can be limits in hardware which are far less than what we need to use in software. Again, callbacks will allow the data path to be written in a way that is oblivious to the underlying hardware limits, because software will transparently fill in the gaps. Hope this makes the use case clear. Regards, /Bruce