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 957C158CF for ; Thu, 1 Dec 2016 20:20:30 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP; 01 Dec 2016 11:20:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,726,1477983600"; d="scan'208";a="907714479" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by orsmga003.jf.intel.com with ESMTP; 01 Dec 2016 11:20:28 -0800 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.79]) by IRSMSX103.ger.corp.intel.com ([169.254.3.91]) with mapi id 14.03.0248.002; Thu, 1 Dec 2016 19:20:27 +0000 From: "Kulasek, TomaszX" To: Thomas Monjalon CC: "dev@dpdk.org" , "Ananyev, Konstantin" , "olivier.matz@6wind.com" , "Richardson, Bruce" Thread-Topic: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation Thread-Index: AQHSRbBkXBK52xh5bEGv2Yak9bo9p6DuQDCAgAUTIYCAACxPUA== Date: Thu, 1 Dec 2016 19:20:26 +0000 Message-ID: <3042915272161B4EB253DA4D77EB373A14F57CAE@IRSMSX102.ger.corp.intel.com> References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com> <1479922585-8640-2-git-send-email-tomaszx.kulasek@intel.com> <15420823.7ghYzVRe3h@xps13> <1734448.0id6dCbsBT@xps13> In-Reply-To: <1734448.0id6dCbsBT@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 19:20:31 -0000 Hi Thomas, Sorry, I have answered for this question in another thread and I missed abo= ut this one. Detailed answer is below. > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Thursday, December 1, 2016 17:24 > To: Kulasek, TomaszX > Cc: dev@dpdk.org; Ananyev, Konstantin ; > olivier.matz@6wind.com; Richardson, Bruce > Subject: Re: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation >=20 > Please, a reply to this question would be greatly appreciated. >=20 > 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=3D1024 > > > CONFIG_RTE_LIBRTE_IEEE1588=3Dn > > > CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=3D16 > > > CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=3Dy > > > +CONFIG_RTE_ETHDEV_TX_PREPARE=3Dy > > > > 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 wi= th Jerin in http://dpdk.org/dev/patchwork/patch/15770/) to provide real NOO= P functionality (e.g. for low-end CPUs, where even unnecessary memory deref= erence and check can have significant impact on performance). Jerin observed that on some architectures (e.g. low-end ARM with embedded N= IC), just reading and comparing 'dev->tx_pkt_prepare' may cause significant= performance drop, so he proposed to introduce this configuration flag to p= rovide 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 i= s not implemented, functional NOOP is used based on comparison (dev->tx_pkt= _prepare =3D=3D NULL). Tomasz