From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH v2 2/2] ethdev: introduce Tx queue offloads API Date: Tue, 12 Sep 2017 20:06:32 +0530 Message-ID: <20170912143630.GA23129@jerin> References: <20170911090543.GA9965@jerin> <2601191342CEEE43887BDE71AB9772584F2497DC@irsmsx105.ger.corp.intel.com> <20170912040107.GA8081@jerin> <20170912055137.GA24921@jerin> <20170912071735.GA29366@jerin> <66688482-9e4e-81d5-195a-6f1a74caca73@solarflare.com> <2601191342CEEE43887BDE71AB9772584F249FFC@irsmsx105.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Rybchenko , Shahaf Shuler , Stephen Hemminger , Thomas Monjalon , "dev@dpdk.org" , "Zhang, Helin" , "Wu, Jingjing" To: "Ananyev, Konstantin" Return-path: Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0043.outbound.protection.outlook.com [104.47.36.43]) by dpdk.org (Postfix) with ESMTP id 7CFEC1F5 for ; Tue, 12 Sep 2017 16:37:00 +0200 (CEST) Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB9772584F249FFC@irsmsx105.ger.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" -----Original Message----- > Date: Tue, 12 Sep 2017 14:26:38 +0000 > From: "Ananyev, Konstantin" > To: Andrew Rybchenko , Shahaf Shuler > , Jerin Jacob > CC: Stephen Hemminger , Thomas Monjalon > , "dev@dpdk.org" , "Zhang, Helin" > , "Wu, Jingjing" > Subject: RE: [dpdk-dev] [PATCH v2 2/2] ethdev: introduce Tx queue offloads > API > > > > > -----Original Message----- > > From: Andrew Rybchenko [mailto:arybchenko@solarflare.com] > > Sent: Tuesday, September 12, 2017 11:28 AM > > To: Shahaf Shuler ; Jerin Jacob > > Cc: Ananyev, Konstantin ; Stephen Hemminger ; Thomas Monjalon > > ; dev@dpdk.org; Zhang, Helin ; Wu, Jingjing > > Subject: Re: [dpdk-dev] [PATCH v2 2/2] ethdev: introduce Tx queue offloads API > > > > On 09/12/2017 11:03 AM, Shahaf Shuler wrote: > > > OK, well understood the requirement for such flags. Thanks for your replies. > > > > > > I think that for simplicity I will add two more flags on the Tx offloads capabilities: > > > > > > DEV_TX_OFFLOADS _MULTI_MEMPOOL <** Device supports transmission of mbufs from multiple mempools. */ > > > DEV_TX_OFFLOADS_INDIRECT_MBUFS <** Device support transmission of indirect mbufs. */ > > > > Indirect mbufs is just an example when reference counters are required. > > Direct mbufs may use reference counters as well. > > Personally, I still in favor to move these 2 flags away from TX_OFFLOADS. > But if people think it would be really helpfull to keep them, should we have then: > DEV_TX_OFFLOADS_FAST_FREE (or whatever then name will be) - > it would mean the same what (NOMULTIMEMP | NOREFCOUNT) means now. I am not too concerned about name. Yes. it should mean exiting (NOMULTIMEMP | NOREFCOUNT) > ? > Konstsantin > > > > > > Those caps can be reported by the PMD as per-port/per-queue offloads. Application will choose how to set those. When not set - PMD > > can assume all mbufs has ref_cnt = 1 and the same mempool. > > > > > > Any objection? > > >