From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0078.outbound.protection.outlook.com [104.47.40.78]) by dpdk.org (Postfix) with ESMTP id 3BFB82BA4 for ; Tue, 12 Sep 2017 09:17:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+KGBSyzEqqiOWiO7Wf89IWTdcBMLipCKYJdt3AiOfzE=; b=hlAkD2stxVb1cphJ5x4egjbxFb5wtoy3LeAgy1ixW3IxZmK3/TPEclvqOHvXE23XyEESht2hTaCwFgwLL0sa4nAPR6e/wEz1byFjefM2C8+Qam/wNxvQjixjgUr+lzWQpdJr+oTWMVgG2vfB4v50OtO6iqQfZeaMsEwL61Fncw8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (14.140.2.178) by BN3PR07MB2513.namprd07.prod.outlook.com (10.167.4.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Tue, 12 Sep 2017 07:17:52 +0000 Date: Tue, 12 Sep 2017 12:47:37 +0530 From: Jerin Jacob To: Shahaf Shuler Cc: "Ananyev, Konstantin" , Stephen Hemminger , Thomas Monjalon , "dev@dpdk.org" , "Zhang, Helin" , "Wu, Jingjing" Message-ID: <20170912071735.GA29366@jerin> References: <20170911062119.GA9342@jerin> <20170911080621.GA15867@jerin> <20170911090543.GA9965@jerin> <2601191342CEEE43887BDE71AB9772584F2497DC@irsmsx105.ger.corp.intel.com> <20170912040107.GA8081@jerin> <20170912055137.GA24921@jerin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.0 (2017-09-02) X-Originating-IP: [14.140.2.178] X-ClientProxiedBy: PN1PR01CA0074.INDPRD01.PROD.OUTLOOK.COM (10.174.144.142) To BN3PR07MB2513.namprd07.prod.outlook.com (10.167.4.138) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2681567c-f946-4137-1694-08d4f9ae63ac X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR07MB2513; X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 3:KusIlA1il7xU1gIyQfEzKDmutktssV6AnV8U715IipeSToO6ZZdieL+ehRfS6pkYLr/eLZgI0QCM8CrYiFoSVW1bJ8wdFPnc7csj9zem2JfJPDWh67OfV6Qm8In/ByHnAzPvobUT5lVoNceUnMgCEOP4SYCi1Orr57ApMgieFKEAdegmhNxXblsWQKA+P5504+ql6uTGe0IArlNbj1ngDRzdUO9kVbkatT+Omag/5x2MeiH+MaEi38PZQS0koyOS; 25:opEGpDdBJfozE8sH1Zn4qZu06Vm9RUTn+ypwVMskBOyV8UuhOcA0UiOeda687PVdMxH6VzvsjgADmJYUdLIz56PlpHGcpJZLLdVTpSnPSqFgpvRjnlV+dUmTePYFEai0hVmmAdFDjNLnXjk603FpVvv3NlC9di9/IyIi5UBZhhKIrnkrLeWlLLz0M8SL98fP/APAUBuWkV4gB58XUzYHM2fChUTA+xmzm5pdLa6GVFzgTHN5CcjGbxZAoiDZPVvuU+SieZEpi5GF641nrEVRTdyvmudJ5EJnCJMn9VmD0ltfRhqqj4qbXOLaYXcgbTMahUzknF/xmRshVXoEscGdtg==; 31:eNfgIr7Kxro9jQJnUuq7uXj7OsQ4S9CXT9eX4SodUrcyXMcK2SQML0zOslfxLHfBAjbzFj4LxiyhcTDuRXhyt5O21gkpI+UMEy8kExIrNMx0c3WJpeirSmObcvf5p5if80j9clikDLN2frYqMEtxauKoe2frN0xkSonMo5Fxb3V+qmd3tUy63fDeBC+lLmMmlOj2FeJVbaMuXBsq3ahW169cmqNC9QC+FU3mtOKlbxI= X-MS-TrafficTypeDiagnostic: BN3PR07MB2513: X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 20:8Q8Q1F/5ghlqcDlUtQ8fbVbTNdM0Utizv5CP0kIyEUsUaqDA3qKEPood/8ZsYfD/8MwBRCwva46qoYjq+H2NVo2ejtx9WFiGShY/3SHQt7ElCFgwbqqH/EaT4hZg0DRzX0/Xl8Yf1Sa/q/BzCFGEuQIvxQdYmkdycbrRG7wSMW+BraLONR+/fwmRyUR0kYsRvMTkUbI/453xuBbrWf98TUcmysUHXop9ZCZbyPp3pUoCmmEEYJqVfv/3cbzsNoxkk2gVubmfLx/F85gwt8crnboyjZA58tTbxNJVsx6pd9nrpMbdnStRI8uE1TKqfQmEyvEP9c/GHYfKTHXK8ZoeWKmfgF9e/fB4W8tODr7DxMKN1YHVpHEmIOJwdXQn0+u1jlMEyvX5SnMnaUIXgTyKpy14pl2JyTLscIN5JlFj2dD5hg1vpUWB7WT//JlBWXccJJym4udauba6B+t6cJ/oAa36Nq2LogJXU3mVOBibBLcOuRUa/1/olKHtjJ2ydKUBk8CXf6U/P7cFPHqm9u4B3gvV6ctN44chdXstj1rfYtJX920dwd8TW4PazuqpdF37ZJ/5Em5z7CfybYp8wLNQy1OVe2c9TXF1exCO+Eixp9Q=; 4:VHP27703ijb78Ckm/eA+LcgCge/tPAdsyS/zYO8dSVDBb1W25yqQbBqlljQFVDItmpArA4rbND0RJ0oKtMhYl1xAsdWFk56Ez7ZTlrvIeHF22kX3US7q+i59GOtgwbCk5gKmetwByr1DpmTRC4JmynNCl+JULGvI6TRDOv59P0uRU1maRMayVEk+B6V5kOaOtdqxXB43etehf7dedbxyl96GUVcnznXZOHY+/HcwVm2WDT6+sV7v34tQ32pCUrBxsydtSysT1tBE3INvqY8XRY15YlGevnEuXo8O4jaBZ/I= X-Exchange-Antispam-Report-Test: UriScan:(228905959029699); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR07MB2513; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR07MB2513; X-Forefront-PRVS: 042857DBB5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(13464003)(377454003)(101416001)(110136004)(2906002)(6496005)(2950100002)(229853002)(8936002)(6116002)(6666003)(6916009)(106356001)(42882006)(4326008)(5009440100003)(81156014)(1076002)(8676002)(81166006)(83506001)(316002)(7736002)(97736004)(93886005)(72206003)(305945005)(42186005)(25786009)(6246003)(23726003)(53936002)(54356999)(105586002)(55016002)(54906002)(9686003)(4001350100001)(66066001)(3846002)(33656002)(50466002)(5660300001)(68736007)(47776003)(33716001)(50986999)(76176999)(189998001)(478600001)(110426004)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR07MB2513; H:jerin; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR07MB2513; 23:5QpywbvqACDf0jFTNr8ZJCYhhuCOU66C1L1W8t6CX?= =?us-ascii?Q?h7Tfo91qhVUkOk06a1jVHxB0qpWKuFNaHE6GMttnTcDlY7vLhiu34HiocEbD?= =?us-ascii?Q?2tHMULYElSowwnZSWLHj+sfWQDr68yRBuqg2SCaEuM2zJhd/e7VxsI5f+nYy?= =?us-ascii?Q?Do9+vrZn9BmdAq5YfIGnWuhzDFRDPNpTa2SmYRQMA0HvSxf+a+3j3z/PU15V?= =?us-ascii?Q?ignw/kolns01epYTlVpNnW1CP/eRMeDka/Kcae5xY1fw00tNf22fkLMr7L2F?= =?us-ascii?Q?vrW55Rxr3CHA8gUkhz4Jdk5AZocDzabPkx1z7uqZfiqz3QsF2osWRJh8RUJO?= =?us-ascii?Q?bSPV3pSOvBBJu8RtVrql7h00ov3/GSw5DqweJT1JhspbZAkTizfXor+GJd6K?= =?us-ascii?Q?kVRxyyfRKkx6O7BodpZH0nJUaQfWbIhC/Za/U2YjuEkvXh45EelygOHu/Nsc?= =?us-ascii?Q?IXkNimDcm8ieIdei7FdcWrbWyzj7qupXgJaevMB0pbRuEemGVZXfcHbPY5RP?= =?us-ascii?Q?FndS2x+TwtaBkvY3UYnlfCiDHcFMGqX66Spk+hK2KYm1PBNforfz9Oxy7bKF?= =?us-ascii?Q?QGgFEBG/GUbjtDV58+MPPiYh423DgK/9t8MACrjSmKVN2FlcTHBYwB370LHx?= =?us-ascii?Q?KqHVLH+7nn87pGwYtEHlKzSNQQAFMBcdDpm5lRMzeGp468MXx6huNNChYKrh?= =?us-ascii?Q?78cXhx0yrSxCrVJ2vdFcgN+Q0CMdB+knxq+LyA//U0mxP2+nkgYfpDBILDKP?= =?us-ascii?Q?6neqeWVQ7QcyzSAs1DKNz3scQTUwg+0qSMmJ/vI0tK+5k8bh9h+9vk1AHULr?= =?us-ascii?Q?Ee2Yzy8yOpJPpygGPj2D46jNIaDHiK+To9otWjSFfGj/BltDC8nbqtQnuQMh?= =?us-ascii?Q?ZcaiC9BeRyGy5C5Sqz3nNEadOUqbYaXfcwmSF6Lv/enih7JRSQEHI+RCzF0X?= =?us-ascii?Q?e1iSaiEji0LbOhTQmbsjjbYA/FuUP9uP69t5SgoT1FPFoh9eipR6KFxPYv4H?= =?us-ascii?Q?sQPQjlPB1PYwLQ7BGiVs6k8sn66Y7a/1Tmtoj44R1rhEUm15My2G89R+pD1t?= =?us-ascii?Q?AAqT34QrcVZ97/j3pGzsHVRK7Yq/olWYS/aFIVUzy0aM//ISe4BWMrZaUZJ8?= =?us-ascii?Q?YvlvzF9Jp3Jx3mRl6cEjfzX7RS8RmaKTeI27rKeaFts74i2YSJhkdiPJuq0z?= =?us-ascii?Q?mICplSi5UjUvmRIoHlIxDBGV7Vx1R0NSzuMrGs0jaBHrBrgkFe/ytAXgpz7J?= =?us-ascii?Q?Pih3Ey3NITcIBIXaKrkThAgGy3CmAzOxhu/OXXnOXHEdHjjJ0EQG+KTikDBr?= =?us-ascii?Q?9CYqGkWniNLHtxaJqSTZnI=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2513; 6:eGPAkGANOgzm/M+/lX3FWvq865AjPMnRGQ0VReTxFZfRizilpe+77bFKUkCYTHES/cdGEsPzREpsLsBI0n90ZDj0Sd8QPHolhZ4qSWu4xKsq7I5uTktFp/8kLBNUuJVZR9WtryCLlXffU7cJCzLp8JdZ2vX0wYIOltfUMMbKK/IyqzeFm8CDbAaJZTgVjW9XeuKe+aYG2DnGjUL/XprgyARsbGpx4orQiJ5+PYq81x2JWDiVou04C6giXU9taepnwtKcAQvyrKvdCuObamwpwqa//mhbV+x+n9GcsxgIqCW8M6Og0y0fcbyhwER0RS/OEp/mFaVvL8H2HM/hM4socw==; 5:WYkpDnxUlvjCYnbJS2AXhOZzuevocpFFkBHZcGYzSo8zAHt4hDyWJEmX7LmVVAQR6c0wcW10jdlJWohDDaHgV8l2VUGoSqwyM0HItST/G8xqgPmH9hHSod+TtFEp3jrtvWCXBZHroTgK5QT3RkLuBg==; 24:xkh3jxO0Je/tkgaOSrRwUus9M+RsUQ0Fb99e039o5/1L8A1ozrebE9Mc4tnurfE0Q1WF1+Y6Ni1OtyH5KfxWU0F26ToQBhUfX+zQxt2BEUs=; 7:dy33IIxLyfmgbdLFDjvoyOGIfNnQPmmYIULuZhb2mG/9rA9OO3uF7ivFXR6hwlpKnP08h3y3OXycU+lTwtto0WWHppVVJ0tNBpDB4e/DSTAxEhqeEOWBJoU4cDrQBlj5qWIoAX1b8Oa9suK+yBxxoKbJQnjPyhez2agMzHKwF0iQCBq0r8PFelRIXMfA9ktYnjG5tbXoPZ510lB3C/BXdp7z5F3wl2PCfbN4xVarw8Q= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2017 07:17:52.6211 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR07MB2513 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 07:17:59 -0000 -----Original Message----- > Date: Tue, 12 Sep 2017 06:35:16 +0000 > From: Shahaf Shuler > To: 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 > > Tuesday, September 12, 2017 8:52 AM, Jerin Jacob: > > > I understand the use case, and the fact those flags improve the > > performance on low-end ARM CPUs. > > > IMO those flags cannot be on queue/port level. They must be global. > > > > Where should we have it as global(in terms of API)? > > And why it can not be at port level? > > Because I don't think there is a use-case that application would want to have recounting on one port and not on the other. It is either application clone/not clone mbufs. > Same about the multi mempool. It is either application have it or not. Why not? If a port is given to data plane and another port to control plane. It can have different characteristics. Making it port level, we can achieve the global use case as well. but not another way around. MULTISEG flag also has the same attribute. But some reason you are OK to include that in flags. > > If there is a strong use-case for application to say on port X it clones mbufs and and port Y it don't then maybe this is enough to have it per-port. > We can go even further - why not to have guarantee per queue? it is possible if application is willing to manage. > > Again those are not offloads, therefore if we expose those this should on different location the offloads field on eth conf. What is the definition of offload? It is something we can offload to HW. If so, then, reference count we can offload to HW with external HW pool manager which DPDK has support now. > > > > > > > > > Even though the use-case is generic the nicvf PMD is the only one which do > > such optimization. > > > So am suggesting again - why not expose it as a PMD specific parameter? > > > > Why to make it as PMD specific? if application can express it though > > normative DPDK APIs. > > > > > > > > - The application can express it wants such optimization. > > > - It is global > > > > > > Currently it does not seems there is high demand for such flags from other > > PMDs. If such demand will raise, we can discuss again on how to expose it > > properly. > > > > It is not PMD specific. It is all about where it runs? it will applicable for any > > PMD that runs low end hardwares where it need SW based Tx buffer > > recycling(The NPU is different story as it has HW assisted mempool > > manager). > > Maybe, but I don't see other PMD which use those flags. Do you aware to any plans to add such optimizations? Sorry. I can't comment on another vendor PMD roadmap. > You are pushing for generic API which is currently used only by a single entity. You are removing a existing generic flag. > > > What we are loosing by running DPDK effectively on low end hardware with > > such "on demand" runtime configuration though DPDK normative API. > > Complexity of APIs for applications. More structs on ethdev, more API definitions, more field to be configured by application, all valid for a single PMD. > For the rest of the PMDs, those fields are currently don't-care. I don't understand the application complexly port. It just configuration at port level. And it is at application will, it can choose to run in any mode. BTW, It is all boils down to features and performance/watt. IMO, everything should be runtime configurable. > > > > > > > > > > > > > > > > > > > >