From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH v12 1/6] ethdev: add Tx preparation Date: Fri, 2 Dec 2016 03:26:16 +0530 Message-ID: <20161201215616.GA10825@svelivela-lt.caveonetworks.com> References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com> <1734448.0id6dCbsBT@xps13> <3042915272161B4EB253DA4D77EB373A14F57CAE@IRSMSX102.ger.corp.intel.com> <2505996.o0gdCe9Hsd@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "Kulasek, TomaszX" , , "Ananyev, Konstantin" , , "Richardson, Bruce" To: Thomas Monjalon Return-path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0053.outbound.protection.outlook.com [104.47.40.53]) by dpdk.org (Postfix) with ESMTP id 52A705598 for ; Thu, 1 Dec 2016 22:56:27 +0100 (CET) Content-Disposition: inline In-Reply-To: <2505996.o0gdCe9Hsd@xps13> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Dec 01, 2016 at 08:52:22PM +0100, Thomas Monjalon wrote: > 2016-12-01 19:20, Kulasek, TomaszX: > > Hi Thomas, > > > > Sorry, I have answered for this question in another thread and I missed about this one. Detailed answer is below. > > Yes you already gave this answer. > And I will continue asking the question until you understand it. > > > > 2016-11-28 11:54, Thomas Monjalon: > > > > Hi, > > > > > > > > 2016-11-23 18:36, Tomasz Kulasek: > > > > > --- a/config/common_base > > > > > +++ b/config/common_base > > > > > @@ -120,6 +120,7 @@ CONFIG_RTE_MAX_QUEUES_PER_PORT=1024 > > > > > CONFIG_RTE_LIBRTE_IEEE1588=n > > > > > CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16 > > > > > CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y > > > > > +CONFIG_RTE_ETHDEV_TX_PREPARE=y > > > > > > > > Please, remind me why is there a configuration here. > > > > It should be the responsibility of the application to call tx_prepare > > > > or not. If the application choose to use this new API but it is > > > > disabled, then the packets won't be prepared and there is no error code: > > > > > > > > > +#else > > > > > + > > > > > +static inline uint16_t > > > > > +rte_eth_tx_prepare(__rte_unused uint8_t port_id, __rte_unused > > > uint16_t queue_id, > > > > > + __rte_unused struct rte_mbuf **tx_pkts, uint16_t > > > > > +nb_pkts) { > > > > > + return nb_pkts; > > > > > +} > > > > > + > > > > > +#endif > > > > > > > > So the application is not aware of the issue and it will not use any > > > > fallback. > > > > tx_prepare mechanism can be turned off by compilation flag (as discussed with Jerin in http://dpdk.org/dev/patchwork/patch/15770/) to provide real NOOP functionality (e.g. for low-end CPUs, where even unnecessary memory dereference and check can have significant impact on performance). > > > > Jerin observed that on some architectures (e.g. low-end ARM with embedded NIC), just reading and comparing 'dev->tx_pkt_prepare' may cause significant performance drop, so he proposed to introduce this configuration flag to provide real NOOP when tx_prepare functionality is not required, and can be turned on based on the _target_ configuration. > > > > For other cases, when this flag is turned on (by default), and tx_prepare is not implemented, functional NOOP is used based on comparison (dev->tx_pkt_prepare == NULL). > > So if the application call this function and if it is disabled, it simply > won't work. Packets won't be prepared, checksum won't be computed. The use case I was referring was "integrated NIC" case where - DPDK target with no external NW PCI card support AND - The "integrated NIC" does not need tx_prepare