From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0065.outbound.protection.outlook.com [104.47.34.65]) by dpdk.org (Postfix) with ESMTP id 9A3DD3254 for ; Tue, 5 Sep 2017 09:08:10 +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=M+vpnFVdHIyerDmpjgmBYj1F+BPb3Hz4l/RJ1gfuEwM=; b=hE7EZ+yTPplXA9Uo2euqDseKOBDhdsJxBw9fz4SWzU2wQ1f5v9MmgRKGsymu3HX/4ZfYhRxmeitG7cNJcRHGprF0YgVRx7dFU5dKhAyBOwsycQqSeU7RAbZ+bllFxJwZrseqbkCNWHyc3OqBspyfHLyqtytHBlKY+v00RmEVqpo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (122.167.99.246) by SN2PR07MB2528.namprd07.prod.outlook.com (10.167.15.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Tue, 5 Sep 2017 07:08:06 +0000 Date: Tue, 5 Sep 2017 12:37:48 +0530 From: Jerin Jacob To: Thomas Monjalon Cc: dev@dpdk.org, Shahaf Shuler Message-ID: <20170905070746.GA14599@jerin> References: <20170828050007.GA10095@jerin> <4428518.N1h1dqvDrp@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4428518.N1h1dqvDrp@xps> User-Agent: Mutt/1.9.0 (2017-09-02) X-Originating-IP: [122.167.99.246] X-ClientProxiedBy: BM1PR01CA0110.INDPRD01.PROD.OUTLOOK.COM (10.174.208.26) To SN2PR07MB2528.namprd07.prod.outlook.com (10.167.15.6) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 453b18ce-9394-4bca-bbc1-08d4f42cdcb6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR07MB2528; X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2528; 3:GmdTrnsToy9OIj+ZtEBB7stjuhDGr+U8ssT+QwtfltZDBU8f5l3P3EiqJHljb1AiEL47RNEKRDGVOANlO+irrS5G3XB6azgrazl3Grr1GRmEuYOalegyXhvWbLvqoksM7bo/AXtf1tc9LDL6Kp8S+daqfsj9riAwWBVz1mfmICRPYYHqporm9avjpSaWKC+pP5b0WztI7LWGhza7/0RBEk8VfggGvD7UEPomDK3hu5iyTxsPsmhZucy/5nbxjLyf; 25:VmY6exhgeTjLQ81ScFg+LpytJJWPBloX8NnA/8MMxyFzPvV8RUucFH/rMPzoTA7IdJpWk713LWGS70JxcxLjfH5UOmOScrIeYdD4TD+rvleStQ5c8zYEsMkuqphOlIjZAhi3tHBoWgoLkId/n2VwwLPWRnNJbArmb5/AwtcX3nnJ5O+SN3HJPjelKRfQ/U81hqHphYfk7CcVfk+2CZ64DsgCbXylAlNot1Hd6BEuo3qoueAw3RBA9JLBEwDdqUPs4+h50Vb6qUNlwER/s+U1eR3RIxwH/0+YoyWfKTnBhVjH3rAcVUHVsKy/YvhI+qf3FiEnUooyli3irY7a+HcVrw==; 31:sNuo02VLQjZNZZf4fx4LZhl0SwxIbxhnfGQyfo/Vw5KynzZV91olpqYhjWSYqTpnSKRKIIt3vkSll2GflfNbwr2QZQaVRGFxv5w4RWL1s+pkt6YPRZcIAAmhp/Y0m1gJsFt2h7uasyWpmylQAp+gea3OoCPwzPxvuRW2vUhSV29G1ZkpRtsUhKpnMQqIr+Ypa1qarIgaYSlZnhGAJH6/7iKaM+Q7b2qn/IDv2GyDNMY= X-MS-TrafficTypeDiagnostic: SN2PR07MB2528: X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2528; 20:nDgiy7wshIfHs5G/Escly1Uy1AWWh4cavFQo2HJbUEu66Okiv269cWkvnE6gtv2pyC/ByKCuLxR9qnQWrgE4rxyJ3wdIokrrmVhOsrfyLOeKj7ttmZA/YPhJDqr7+M6kNMb6sSvoIc6Bxl3TIGzIY+ZBTwB9GsFw73G170w2IPoSwsh9EaY2xgMlgI5M14LT0SKHDge5c3WuK3Nv2oYGJE6vvQNK5QkLoqSexmHTx6F6vrV02pylHuoehpNAetIDuKeLoO/mkIeXGQq63AwB5veouIz7NXFm8iury/Qp3h0ICTll6o8M9O6ctreqm8T6r4Xe1j7C1q2gZ+vvNDzVtGtlggHWIAjOB6JoJvUh/veiI9RvE+OZc6nvZ1gkC/9OLFEgl9eXUj9zqNDHKA3eouZ6GZsFKkR2QOH3DZ39X+q2e2Znk8Ei8PgVoWEazqdBjVVPseW67MsdbNt+alFsEy3zI14RC+hRL1AnX8dqqLIH0R0lp1ne3dHTRC+L79bqV/Gl8l4IbrmFasS9u6Xwi8qD/Euy2cuLp7IKqE14RCJaeDb/+g/3jQPYhZhPpcZsUHmhDKZ9NLkSa4igl54XUHUmtuOKE8ksjPG9H1kaTeY=; 4:ifRrX3cIjKjkEoSjKGyuWM6qXC+jOIbuDdxx6fRQWhUV3QxXiY4L+ED3V3zYLC2Y/s+fl6A4onKwgYPHKDv8r/VcnmwprMlVTJqCWYrYma2hM3eixcu2ZxhS8x8/wBBSF7QhlXE9vyUlQ065mp7gpu4GiaAsUUdHt8f/B9Mix01MCP+Loe2TJEBS1xyUdQpBh5puSSDAI44D3vuLcyd4dnNJb5shStFC4D0Q0QLGTEgutRNuSot1mgh0uhFpyEeVVbPtIXjPLi14Bd1E5owhuH6Y76h8oFmkXe7mKdcNeGg= X-Exchange-Antispam-Report-Test: UriScan:(278428928389397); 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)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR07MB2528; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR07MB2528; X-Forefront-PRVS: 0421BF7135 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(377454003)(199003)(189002)(229853002)(50466002)(189998001)(33716001)(9686003)(55016002)(2906002)(5660300001)(93886005)(106356001)(66066001)(6116002)(23726003)(47776003)(1076002)(105586002)(6666003)(4001350100001)(33656002)(50986999)(3846002)(54356999)(76176999)(2950100002)(42882006)(6916009)(42186005)(8676002)(25786009)(7736002)(97736004)(83506001)(4326008)(68736007)(81156014)(478600001)(53936002)(110136004)(6246003)(6496005)(101416001)(8936002)(305945005)(72206003)(81166006)(18370500001)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR07MB2528; 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; SN2PR07MB2528; 23:+lOWNqC+ycAdSAWUiHnHuMloJQWuv5E3LhFkAxy7F?= =?us-ascii?Q?y4M5hhlNi6hrySEpVjrVnPE3I8hRxGprHuir3eccFybUfWMwqL08paHtOsYZ?= =?us-ascii?Q?jEuWq5K56mRjxYw2uV5LrWW1YcvWDWhlZr0pkoZsyM3Tl4PXRWqiaS96HfDQ?= =?us-ascii?Q?ksXwBt71uuF0LqYIX5vvnzCenxJu85pAn4BHUlU32BdE9lFuKuZtvd4y+MXD?= =?us-ascii?Q?1RlWE7qcsr2HtwHC+dugCcsnUrzoacwmyxsAPsUD9FDXlje9f/t189mOdvRX?= =?us-ascii?Q?RHoUNWAGoaU1B1v0ZnZL93djIfxgudlviGM7k2tWtKRvblzEYo6bnuLA+CPq?= =?us-ascii?Q?cVPcXrFWxnlC5piW+qY2bjAGB/Y0o7sIXD0L1+ZhbTubuEZqL+CkOVlMPtP2?= =?us-ascii?Q?XT01DiBhY2H6MnNDLfF5CVcYRSEn4VLiKjxG9RqqCAl3cimBNDAl8iKkZBMC?= =?us-ascii?Q?i5oRKYcKqL9QwKfokkVlTmIvAkJvdJI4krumMC6SBDJ0ydmwM+466Y7sL9D+?= =?us-ascii?Q?KCPHWKs+goZUzAb+pNZ121zdqbX1dkFM0VAnPXYadGQ7vK2ZJDNSYSeh+f9Q?= =?us-ascii?Q?zizxYbqmZ4Uh7DK8Ew0SaS0K4AeWz8I82D02oDzDTE4LWmEKEL6Uqstp6sRJ?= =?us-ascii?Q?GF2YP+xuXA0Kt/hDHSiyr9qjXn6iqVFWhdRYeMaJp7HMqesscAISMc9X2X7i?= =?us-ascii?Q?dI5CJTa16yqAYk0t2KLk3MaLYlpcWeMOvhPctuImFUvK5UC9rbKcnTWlRirn?= =?us-ascii?Q?NawPBu3kl1e3h8LX2nUu7xNduiZlX3gdmG6i8ZjZZ/v9yhMZqJDr+txOLvBT?= =?us-ascii?Q?L0TPolCN+DuRSMzYW7ZPlLvluHwg7WmvrqTEyoMk5ENPOTjyGt8ZHvFktIpL?= =?us-ascii?Q?SFZ7hUJpI7FKV8/JgzHNoKLKHkqaUnNEKMQ5fW69ru46BMcBtaC61lOJ1AhP?= =?us-ascii?Q?MWVOpkfcH5H91TsZU7tFupg7yuMrEEJoVquuJaHEQ82xv5G5J5RB00SQO+Eu?= =?us-ascii?Q?AQtsVomsKJXw6J7Xj3+lWcV1jCQZ/+M3RbA3NkP1aQ0eTjG0x41mBel7tUpn?= =?us-ascii?Q?HFp65NTxYq48clw6R8t725G8wfKrx+U/9rRPm0NcNCcIsD/sDC2Ae2USiSNY?= =?us-ascii?Q?TeihrIQdAkP7SKWwPUQ58K1asB1uf+r3F8skYOmBgK8wZi0hyB8E0eGrgsPk?= =?us-ascii?Q?uHy7IdBg9uLcq3y3k2cTwuXGLkNEKZS2Dbu3/iMNe9VClUPB/iUenKQwg=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2528; 6:RcV84akFKHORN5hSQBVC4m/kWbKDoihtp5EwCOJlJjwU9eop1PNVAKawMPoZ/W58oQKTw57lV+q0G062UOaQZoYAmrxEz8CuoeGs/T285N6mZp9yEYssDJrfKVM44QnCX+pwqCuigW51J7dqRufdUEk7GIeieD4MpUkhnCgT0fQDmpyrUHPBIkPNF8KXEMHoV+YjBcKqrmQhrcJi8buZsyUY4JhgJely8gYTNTecbIUXJ3PapeVsV4aFBrpHhbGWYFqh42uNsdGyEg5Fk05+dShJO8hLegBd+h2MGnzAFG6KKfz4bNrMNOMfokQwU1NvHz8IrjDXb/eLeV4ToQF3KQ==; 5:Yv9K7XqCkTy/0wUVKSFSW9K7AlD/us+JCBuhTMbTqrHZ3HdZ0WdgRwNBVuOR0rgJBRHfY/nWkM06nFvJR6oVWz0rHSisVgQYhSyXnHsbMj7OFrZsZGAIyv0XOK9r7HgUhcG+LuxkghXOCozaJpn7KA==; 24:0rQHRYLdxxl1GE5YXJNuakp3IlKaGlgETdWPqoM3TRcNRf3Lj38Ov64OiOgJzlu5IyhHUbwANDYNNJsz3OXv9u3mz61O+Vezx5b163oV5SE=; 7:w90B7xca+PBpIGkWuDzPq/49ylPcguAIL7i/9tkGqjESPivnHNWrV3OmgywrLHinalU9XISfJNewK3lqiVVilJ1mPZDWZq3dJewCXigDfJjY8jl19e7+0mEk1cY4HrAwVK93HkahGKxf/7mClX8wvk0FWJq6nCAETgoCbMa2DUETZJgcQdT15U/aCST6Zpjen/NKCKlvdKtG2xmjMQlfNZ0+x8MpT2OfpXhBEVB+KUs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Sep 2017 07:08:06.8221 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR07MB2528 Subject: Re: [dpdk-dev] [RFC PATCH 0/4] ethdev new 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, 05 Sep 2017 07:08:11 -0000 -----Original Message----- > Date: Mon, 28 Aug 2017 12:57:13 +0200 > From: Thomas Monjalon > To: Jerin Jacob > Cc: dev@dpdk.org, Shahaf Shuler > Subject: Re: [dpdk-dev] [RFC PATCH 0/4] ethdev new offloads API > > 28/08/2017 07:00, Jerin Jacob: > > From: Shahaf Shuler > > > Friday, August 25, 2017 1:32 PM, Jerin Jacob: > > > > > > > > > > The new API does not have an equivalent for the below Tx flags: > > > > > > > > > > * ETH_TXQ_FLAGS_NOREFCOUNT > > > > > * ETH_TXQ_FLAGS_NOMULTMEMP > > > > > > > > IMO, it make sense to keep those flags as PMD optimization if an application > > > > does not need reference count and multi mempool in the application. > > > > As example, An non trivial application like l3fwd does not need both of them. > > > > > > The l3fwd application is yet another simple example from DPDK tree. Am not sure that a complete vRouter/vSwitch implementation is with the same characteristics. > > > > But not all dpdk applications are complete vRouter/vSwitch implementation. > > > > > Moreover, I think the fact there is an application which is able to use it is not enough. IMO there needs to be some basic functionality always provided by the PMDs and not controlled by flags. > > > For example, let's say we have an application which always sends the mbufs with the same ol_flags, or even with the same length. > > > > Does ETH_TXQ_FLAGS_NOREFCOUNT comes in same category like mbuf->ol_flags? > > > > > Will it make sense to add more flags to control it? > > > Will it makes sense to run RFC2544 benchmark with testpmd io forwarding with those flags? > > > > > > If the answer is yes, maybe those flags (and others to follow) belong on different location on ethdev. However for sure they are not offloads. > > > > I am not sure about the reason for opting out mempool related flags. > > In the context of HW assisted external mempool managers, Enabling reference count is an offload > > from Ethernet device. > > For example, with external HW assisted mempool, ethdev driver needs to > > have different way of forming TXQ descriptor in case if reference count > > is enabled(as, in the case of HW assisted mempool managers, bu default, > > HW frees the packet on send) > > > > I am fine with moving the flags to some where else if it is make sense to you.But > > from PMD optimization perspective, I think it is important have these flags. > > Why not. > We can have a function to enable such optimizations. OK > However I am not sure ethdev is the right place as these hints apply > to any mbuf. I think, We are talking about the mbuf behavior when working with ethdev TXQ here. Right? IMO, it make senses in the ethdev layer. We pulled in ETH_TXQ_FLAGS_NOMULTSEGS flag for the rework even though it is related to mbuf. If you think, ETH_TXQ_FLAGS_NOREFCOUNT and ETH_TXQ_FLAGS_NOMULTMEMP should NOT a be PER TXQ configurable flag then it can be moved to Port level TXQ configuration at function: rte_eth_dev_configure() struct rte_eth_conf::struct rte_eth_txmode: I think it is important for The ARM64 architecture to optimize for the application which does not need reference counting and single pool configuration like l3fwd. Reasons: - The NPU class ethdev hardwares are tightly coupled with external mempool ops with HW offload, and there is provision to utilize these features - For the general purpose arm64 perspective, At least for the low-end systems, the cache hierarchy is quite different from x86. So its costly to deference the mbuf area(which stores the mempool handler) after the Tx free. We can support both use cases, just that it should configurable based on the flags by the application. > Please Jerin, could you work on moving these settings in a new API? Sure. Once the generic code is in place. We are committed to fix the PMDs by 18.02. Jerin