From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id E4EDF4A59 for ; Wed, 30 Nov 2016 11:30:58 +0100 (CET) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP; 30 Nov 2016 02:30:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,573,1473145200"; d="scan'208";a="37286348" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga005.fm.intel.com with ESMTP; 30 Nov 2016 02:30:56 -0800 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.79]) by IRSMSX104.ger.corp.intel.com ([169.254.5.52]) with mapi id 14.03.0248.002; Wed, 30 Nov 2016 10:30:54 +0000 From: "Kulasek, TomaszX" To: Thomas Monjalon , Adrien Mazarguil CC: "dev@dpdk.org" , "Ananyev, Konstantin" , "olivier.matz@6wind.com" Thread-Topic: [dpdk-dev] [PATCH v12 0/6] add Tx preparation Thread-Index: AQHSRbBWS4tmW4XP4UaKFIgTyIGT9KDuQp0AgALr7oCAABOOAIAAChdw Date: Wed, 30 Nov 2016 10:30:54 +0000 Message-ID: <3042915272161B4EB253DA4D77EB373A14F57A50@IRSMSX102.ger.corp.intel.com> References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com> <8317180.L80Qf11uiu@xps13> <20161130074003.GD10340@6wind.com> <2285429.Z7YL4y4ekv@xps13> In-Reply-To: <2285429.Z7YL4y4ekv@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v12 0/6] add Tx preparation 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: Wed, 30 Nov 2016 10:30:59 -0000 Hi, > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Wednesday, November 30, 2016 09:50 > To: Adrien Mazarguil ; Kulasek, TomaszX > > Cc: dev@dpdk.org; Ananyev, Konstantin ; > olivier.matz@6wind.com > Subject: Re: [dpdk-dev] [PATCH v12 0/6] add Tx preparation >=20 > 2016-11-30 08:40, Adrien Mazarguil: > [...] > > I understand tx_prep() automates this process, however I'm wondering > > why isn't the TX burst function doing that itself. Using > > nb_mtu_seg_max as an example, tx_prep() has an extra check in case of > > TSO that the TX burst function does not perform. This ends up being > > much more expensive to applications due to the additional loop doing > > redundant testing on each mbuf. > > > > If, say as a performance improvement, we decided to leave the > > validation part to the TX burst function; what remains in tx_prep() is > > basically heavy "preparation" requiring mbuf changes (i.e. erasing > checksums, for now). > > > > Following the same logic, why can't such a thing be made part of the > > TX burst function as well (through a direct call to > > rte_phdr_cksum_fix() whenever necessary). From an application > > standpoint, what are the advantages of having to: > > > > if (tx_prep()) // iterate and update mbufs as needed > > tx_burst(); // iterate and send > > > > Compared to: > > > > tx_burst(); // iterate, update as needed and send > > > > Note that PMDs could still provide different TX callbacks depending on > > the set of enabled offloads so performance is not unnecessarily > impacted. > > > > In my opinion the second approach is both faster to applications and > > more friendly from a usability perspective, am I missing something > obvious? >=20 > I think it was not clearly explained in this patchset, but this is my > understanding: > tx_prepare and tx_burst can be called at different stages of a pipeline, > on different cores. Yes, this API is intended to be used optionaly, not only just before tx_bur= st. 1. Separating both stages: a) We may have a control over burst (packet content, validation) when ne= eded. b) For invalid packets we may restore them or do some another task if ne= eded (even on early stage of processing). c) Tx burst keep as simple as it should be. 2. Joining the functionality of tx_prepare and tx_burst have some disadvant= ages: a) When packet is invalid it cannot be restored by application should be= dropped. b) Tx burst needs to modify the content of the packet. c) We have no way to eliminate overhead of preparation (tx_prepare) for = the application where performance is a key. 3. Using tx callbacks a) We still need to have different implementations for different devices= . b) The overhead in performance (comparing to the pair tx_prepare/tx_burs= t) will not be better while both ways uses very similar mechanism. In addition, tx_prepare mechanism can be turned off by compilation flag (as= discussed with Jerin in http://dpdk.org/dev/patchwork/patch/15770/) to pro= vide real NOOP functionality (e.g. for low-end CPUs, where even unnecessary= memory dereference and check can have significant impact on performance). Tomasz