From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH v2] doc: announce ABI change for rte_eth_dev structure Date: Wed, 27 Jul 2016 22:40:45 +0530 Message-ID: <20160727171043.GA22116@localhost.localdomain> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "Kulasek, TomaszX" , , "Ananyev, Konstantin" To: Thomas Monjalon Return-path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0054.outbound.protection.outlook.com [104.47.38.54]) by dpdk.org (Postfix) with ESMTP id 6F0055594 for ; Wed, 27 Jul 2016 19:11:06 +0200 (CEST) Content-Disposition: inline In-Reply-To: <2146153.nVzdynOqdk@xps13> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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_desc_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 packets. > > > > 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 expected behavior ? Anything think it as compile time to make other PMDs wont suffer because of this change. > - 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 ;)