From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 133C3377E for ; Wed, 27 Jul 2016 22:51:13 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP; 27 Jul 2016 13:51:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,431,1464678000"; d="scan'208";a="1030357635" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by fmsmga002.fm.intel.com with ESMTP; 27 Jul 2016 13:51:11 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.102]) by IRSMSX154.ger.corp.intel.com ([169.254.12.208]) with mapi id 14.03.0248.002; Wed, 27 Jul 2016 21:51:10 +0100 From: "Ananyev, Konstantin" To: Jerin Jacob CC: Thomas Monjalon , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v2] doc: announce ABI change for rte_eth_dev structure Thread-Index: AQHR6C4vhCk5+MDYj0GuIonGmNNwxqAsvetQ Date: Wed, 27 Jul 2016 20:51:09 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836B88894@irsmsx105.ger.corp.intel.com> References: <1469024691-58750-1-git-send-email-tomaszx.kulasek@intel.com> <1469114659-66063-1-git-send-email-tomaszx.kulasek@intel.com> <2601191342CEEE43887BDE71AB97725836B80AD8@irsmsx105.ger.corp.intel.com> <2146153.nVzdynOqdk@xps13> <20160727171043.GA22116@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836B8884E@irsmsx105.ger.corp.intel.com> <20160727174133.GA22895@localhost.localdomain> In-Reply-To: <20160727174133.GA22895@localhost.localdomain> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for rte_eth_dev structure 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, 27 Jul 2016 20:51:14 -0000 >=20 > On Wed, Jul 27, 2016 at 05:33:01PM +0000, Ananyev, Konstantin wrote: > > > > > > > -----Original Message----- > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > Sent: Wednesday, July 27, 2016 6:11 PM > > > To: Thomas Monjalon > > > Cc: Kulasek, TomaszX ; dev@dpdk.org; > > > Ananyev, Konstantin > > > Subject: Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for > > > rte_eth_dev structure > > > > > > On Wed, Jul 27, 2016 at 01:59:01AM -0700, Thomas Monjalon wrote: > > > > > > Signed-off-by: Tomasz Kulasek > > > > > > --- > > > > > > +* In 16.11 ABI changes are plained: the ``rte_eth_dev`` > > > > > > +structure will be > > > > > > + extended with new function pointer ``tx_pkt_prep`` allowing > > > > > > +verification > > > > > > + and processing of packet burst to meet HW specific > > > > > > +requirements before > > > > > > + transmit. Also new fields will be added to the ``rte_eth_des= c_lim`` structure: > > > > > > + ``nb_seg_max`` and ``nb_mtu_seg_max`` provideing > > > > > > +information about number of > > > > > > + segments limit to be transmitted by device for TSO/non-TSO p= ackets. > > > > > > > > > > Acked-by: Konstantin Ananyev > > > > > > > > I think I understand you want to split the TX processing: > > > > 1/ modify/write in mbufs > > > > 2/ write in HW > > > > and let application decide: > > > > - where the TX prep is done (which core) > > > > > > In what basics applications knows when and where to call tx_pkt_prep = in fast path. > > > if all the time it needs to call before tx_burst then the PMD won't > > > have/don't need this callback waste cycles in fast path.Is this the e= xpected behavior ? > > > Anything think it as compile time to make other PMDs wont suffer beca= use of this change. > > > > Not sure what suffering you are talking about... > > Current model - i.e. when application does preparations (or doesn't if > > none is required) on its own and just call tx_burst() would still be th= ere. > > If the app doesn't want to use tx_prep() by some reason - that still > > ok, and decision is up to the particular app. >=20 > So my question is in what basics application decides to call the preparat= ion. > Can you tell me the use case in application perspective? I suppose one most common use-case when application uses HW TX offloads, and don't' to cope on its own which L3/L4 header fields need to be filled for that particular dev_type/hw_offload combination. Instead it just setups the ol_flags, fills tx_offload fields and calls tx_p= rep(). Please read the original Tomasz's patch, I think he explained possible use-= cases=20 with lot of details. =20 > and what if the PMD does not implement that callback then it is of waste = cycles. Right? If you refer as lost cycles here something like: RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->tx_prep, -ENOTSUP); then yes. Though comparing to actual work need to be done for most HW TX offloads, I think it is neglectable. Again, as I said before, it is totally voluntary for the application. Konstantin=20 >=20 > Jerin >=20 >=20 > > Konstantin > > > > > > > > > > > > - what to do if the TX prep fail > > > > So adding some processing in this first part becomes "not too > > > > expensive" or "manageable" from the application point of view. > > > > > > > > If I well understand the intent, > > > > > > > > Acked-by: Thomas Monjalon (except > > > > typos ;)