From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 470FC1041 for ; Tue, 12 Sep 2017 16:44:09 +0200 (CEST) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id B168820070; Tue, 12 Sep 2017 14:44:08 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx2-us4.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id D1FF860055; Tue, 12 Sep 2017 14:44:07 +0000 (UTC) Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 7192D2006D; Tue, 12 Sep 2017 14:44:07 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 12 Sep 2017 15:44:00 +0100 To: Jerin Jacob , "Ananyev, Konstantin" CC: Shahaf Shuler , Stephen Hemminger , Thomas Monjalon , "dev@dpdk.org" , "Zhang, Helin" , "Wu, Jingjing" 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> <20170912143630.GA23129@jerin> From: Andrew Rybchenko Message-ID: <4027c960-f98f-df72-a12e-65545ca87cb5@solarflare.com> Date: Tue, 12 Sep 2017 17:43:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170912143630.GA23129@jerin> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23324.003 X-TM-AS-Result: No--11.123000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1505227448-ukz9gEW9O8aC Subject: Re: [dpdk-dev] [PATCH v2 2/2] ethdev: introduce Tx queue offloads API 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: Tue, 12 Sep 2017 14:44:09 -0000 On 09/12/2017 05:36 PM, Jerin Jacob wrote: > -----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) Merging these two flags together is OK for me as well.