Message ID | 20170711061631.5018-2-santosh.shukla@caviumnetworks.com (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id 537F17CB1; Tue, 11 Jul 2017 08:17:34 +0200 (CEST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0080.outbound.protection.outlook.com [104.47.32.80]) by dpdk.org (Postfix) with ESMTP id 725727CB0 for <dev@dpdk.org>; Tue, 11 Jul 2017 08:17:32 +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=oz/MZVJjPu0seUQec2S/u4ajiOFBe8NCtx2QHSMUnNQ=; b=hfmEXgpVNoHfjaP0hzi+mwahmcayMKITqPL1uBID5M5VpPFiNqmcoBMsyELszkcNLzM32ieMOvx7w9Nfuw/niFokd51FBmM7fGev9QfEK1QmhIXCN7ijcLFo2jqTkiGgEJHEjjcyYLdqhM9+LJxKsFWV3AAjD81M1GnnjqAUr/U= Authentication-Results: monjalon.net; dkim=none (message not signed) header.d=none;monjalon.net; dmarc=none action=none header.from=caviumnetworks.com; Received: from localhost.localdomain (111.93.218.67) by CY4PR07MB3094.namprd07.prod.outlook.com (10.172.115.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Tue, 11 Jul 2017 06:17:25 +0000 From: Santosh Shukla <santosh.shukla@caviumnetworks.com> To: thomas@monjalon.net, dev@dpdk.org Cc: bruce.richardson@intel.com, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com, shreyansh.jain@nxp.com, gaetan.rivet@6wind.com, sergio.gonzalez.monroy@intel.com, anatoly.burakov@intel.com, stephen@networkplumber.org, maxime.coquelin@redhat.com, olivier.matz@6wind.com, Santosh Shukla <santosh.shukla@caviumnetworks.com> Date: Tue, 11 Jul 2017 06:16:21 +0000 Message-Id: <20170711061631.5018-2-santosh.shukla@caviumnetworks.com> X-Mailer: git-send-email 2.13.0 In-Reply-To: <20170711061631.5018-1-santosh.shukla@caviumnetworks.com> References: <20170710114235.18970-1-santosh.shukla@caviumnetworks.com> <20170711061631.5018-1-santosh.shukla@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [111.93.218.67] X-ClientProxiedBy: SG2PR01CA0103.apcprd01.prod.exchangelabs.com (10.170.138.157) To CY4PR07MB3094.namprd07.prod.outlook.com (10.172.115.8) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7fbb1f1f-55f8-48a4-ccfd-08d4c8248233 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR07MB3094; X-Microsoft-Exchange-Diagnostics: 1; CY4PR07MB3094; 3:AnhW2M8stuNJGY9/Pv+c63BIS/ASTZmzpT/lrUM+E+5YwG8IN/Kfne8J+36Cq7aOE67WExgb+7FlX/5SNlzH+U9eZ1NQR3FCnbpD1zHDLsSjDbt88R8TzaYqr8nvrCP0trKm50EnG8C1ZJHQ9MJl2cegmdTNPOCnHuLYm1oeEtZPHwVFW8vJfMBwMhhFle35rwfG+H17gXn1NFZ2xG87i4S8C/dd2Ed5U76RTvlsBlUw8cdcZTZPG736iCCx0O2ABuclHfY6g+aUzqL5wLpwrS3xaneTTqU2t3laeF0L7yTkX2YYt02aC042ITtayHf7TpRd3lp/kJq8QhmZKo9RADZexhLYT5Lhz3SSyCrE8JXCo4omfqS/ZB992r8BmMLUU/NdFxHM3Ot2XhlKkDI3R+Q4eq39QvG9hbB0i8jmkNlBAQB+NHygq4HIkb4kpAITwAVxpVg18sjhUDjT1DD0XKUSjUJkK7rQSd2pEZTnZPwKpviYBT5N+pYJH4viPVgKoHGF05k7ySBEUhDJNRpCJIOyybGQj5gPfaDXzX0IgNKY3WUjwZeXtMaLSgFGZ1p9Hv6+LHZZRDLGqMd8N4tuDrPs+JJ34Q2gOJ1dI9nbfVNpS0VREZBk41k9SBjuF+LzAiR0AokOi+SuYZCKs25UPd2dfIQ3ecX5MF0Npkwsg1iaag57rd45RYv5olVvOrm7w5yA94j68/wo5eN4/SIQb1gKOl/4RVZ2FUEoN9eewH0= X-MS-TrafficTypeDiagnostic: CY4PR07MB3094: X-Microsoft-Exchange-Diagnostics: 1; CY4PR07MB3094; 25:gcQNJ3hzOKk7EFm36qdeCw/lKnY4eIgo3gb8PRdvpjjXutw/UUwZcFMT+t3nrD8e1riYb77+gvDh+NypDej6gPbRCCE7fIL0r69mQBfVfshBG7ucbrDILOr5GCAwXeGPb3dFK5gNs/jlk9q/kBQ3U+HN/9krvhRd3/wqQ5wNKVhzJT1OtehYYDCXk0CkNsBtcYbkTYvp9T8TPb/WfFtf2cWgp6E50pmQHA9fF2giRfiVZ2rCIx8MPssxuUqGv8QDZRrsk9XNbRboTR3yZ9phnrY8BNbJKxs1sbFvRdukDh1GzEPRkJnX0cZVrAaFh3CNlH3+dkYVdNyqm5w2umW5QWDJsb6ON4Z6wYZju5GSC8TWn/k9ni4Yr1uXjtEztY4VAX690SeH5H8s/tO3HN0ZmglQ4aE77IRetDgH/ENnMj/cWc8i1jVSErSHs7KTfPUmPqb0JiJW+9mog1unEOfcpxoAmDFpIpBN6VbD0OGalskrXh97/ZQzMx5HiwdLJPkw3zYIwP33eOWvSLljCeTBYJSfOXGc1FO5z9vZ/J+gK7eoY+nRINfyGks0ultLKBxZ9/nsS+WHTJD+GCHqERyhRz2LiqOLg10Fxl2Mt9DtXloUzNNNGQjoMytucyfJl7mxyEhAyX+cNZtDsJMTLkLVOzHPds+JgillUVC57xDiHh6TtbjoMgT8BQF1hUg0nMJmFaZMlOnhiDNCJdYNbyhGVABHorQVgaO1PU5PUpKckxR8bXi9FdtbmVsMlRraMJ6oNCW6iQkPud+A/iPyMWRPK1C0CH+GRdEObCr3p3CIJK0HLZ1zBej4rZkVXNEM30JIpqqldqDhYtU+b3MjbtrV6GGtwtcxMTGDLHWUSedSxeaFYc3+4XbgGdkifZlJIwmQT5f67wlyVZjPvH4peKGLQweAfIaJfwqtILX6WFeWSaQ= X-Microsoft-Exchange-Diagnostics: 1; CY4PR07MB3094; 31:2Ekjq6VAN437+asod0Xj/0plsugT+yNFeAg5E2eMosBUWxJ6ax/Rqnxpau8BX4SbcTo0cXEctsxbt4PkWgluekC+gwkmiSIDxUfo46vpSMMtYEWOruwd9/ndoLtkjr8btY4EPXBWvj01azzBfmfOVCiP4exfdEExfOUuZBBTneAQ41hKe3MREo3VNw9VHHcnUSsfTGKBAg+3g659tvgF4BOUZArgB7GGz0VkcjuprkbXn3GjLzqUHKUf/O1OUqmI8xusgSdWwPgp8U1ShkVVY7onGsASQFyp9prlZayrFbrP+JZmr9l0whc2QQ74PRDuIA2m7oi+z5AU95YE4owJiXqvDI/iUU/yJvhLUmOCxNAP/1GdEOeVU3k0ixabF9JL4ffhZ2BQd7gak4PU96usmtAxPGS8aZ8B2edpRVG6EnWGmCZkYzq1yvtUvpIO3rDyH/EsxEUMLql1uVDmVKNEY8r3GmwRekCDxa4UYHAD+gDdByzmEF3XCaLaLpF7t/a+3sNpJ6l/oa+HV0Ked85RsxpCtij+D5nLRezUvD5dEJ2B6QDDuM+tdeAY90eiycRk4Y6TFVNw+0KnlrmAULMoktV76aOrtIBUd994rTbkCTHYrn8gq+TnSv2Dz9VuNd4ifzsKorBYjoaZWn1HeSLZg2NJKo5HOJ9oEVIgq5SHOz4= X-Microsoft-Exchange-Diagnostics: 1; CY4PR07MB3094; 20:ITG8SJ9xJxqpegpxKX3/dOYetlTA9VwO3ZEyoMhaChF2ftsbx8eiG7r1YdGvUc8T5decglADrxdxp8Jg2xTmV+ZqNao/cP+Hdh0ly4AiGA+pZxxyUQHdv9qx/cOlYopPaUPAMyGkqGefGiXK8Y9suYRXTG6/Ws+boulqcdsmYptbW6Av5DDAhFfzDnBiFZiFmxZlHcxAilLTJmxSGoycAAKvyqQ77YVSH1y5Sl+dAWTHS6s+fkjPnfEY4DcuyWA7oXd+6UUCK260UbdKnj1AWJD/ESRR68/rTVuSkxBNiLYXTtAsCh4j6fKQWV7iVLCyOd+SysvD+CgErTGxjC88mHqTRs9cSE07jqCEFVQn3NFs+9+OFfFnm8gu80hn2qFgdq/KDgbEkqpGH5rqUSu1HjKJNCfKcXY32O2kx3q8cry4An5j+4IfW9mjC6q3fWkxYI7pro96XvIH1VKXbZxmKc3PZZwiJqdZAYOQhgYPpveRimeW+EQyaPQ884nAXjah5eUtzmvnnj8boAuwjTsDN6WbikCLjSpdfDieZlo8M21gO3flpSQsBicTOGzEnn/cqzV/+h9LQBjgFiAG2p0R6cg/yOEu9Tw0eW+encXwNwA= X-Microsoft-Antispam-PRVS: <CY4PR07MB309448AEE610D226DDE58D34EAAE0@CY4PR07MB3094.namprd07.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:(236129657087228); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(6041248)(20161123560025)(20161123558100)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR07MB3094; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR07MB3094; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR07MB3094; 4:zAj5AqLFRKg2yrDf85G3X+a5CelWvChjVgcQflvpI8?= SffPdg4Pp1fYVx6X1sglz0yuHLd2hTd6KrLoQj+Fuxjx5Ga6N2zPV0uePqzuU6fjmSzAj5sBiPZj5CrmdS3DcSRNDpUbdOqX2uXNrA8w66yX7tG5cQNwRMbuOjXytVBptgd1ddhcWGd3/UFXJouLSaY5I851/WzCa/ab1/N4KuYHWcgfMX/FL1YUeDBfu3ic1t2skdDFx0Dur4cd0GH8rKHusw8iBki6LR5sFD24ZAkib4aIgcREC5vBobPAKq1FuDxi2/c2Pjm6N+Vt/TRxk7ci0YXrrwDy3//1bCc/WMdOyd4NpzONILSCTR/aEEMWGFLhZNcNioGDo2cv3Tg9ZdswVoxe6IgHK5zdkfjZEcsPrucsTvOzXw8qIun5LQqqPPlc6aYjS25K8ai+cl5YigCSTbhIaOvZ9s0Q9wtPx3AiOWNYRk4aTIqqx/d3ZhENd/AZq9BmT9guj+68Jp9TshV0j7BvekfBJQIuJ3XQBj0QGctv4h+Cu4JjHDi5BXSZHwGyuuZFuDXG457lRkZkNlU8+jBKpdc5nrQzjFSsoDFkEb/fqLwJMJRvlpOcu8xzR4pYSr+fdLac4goNl/VPQIeD81aQtHCb8mYZ1DAzEFT7nex1OWemEOn5iBE4rTsKPMWuNQ8fBMuacfhnbHI4W1kBIrBRhPWVxBTbPuE24YcU6NVCgmP9wBOYocVNFPCeBWeTnU2DfY+Pjai3pVAEXxOZIxP2ODTBExMsncdXZXJ1jwDAHuV1Ytt7wP4Ee9yL1ovXDFPKMCiY82n1p2SeXRzWtP3FSuCvyICh056pXBna5dNQAQy2N5RvL4JZa17qpPbNTnustBHCb8t2dAFOger2GSiyISdLEkTOC3PbFzrgDR1U8hUObGFm3g/XsrKXlwhgBEkNkVHIkBnZLCDawEY5de62iKTCW0qqhLEcQtiYVZTf1qXClW0Q1xt5kCoHlynd08MGQbK4uuHWusOehqoEFZi6JH+CRwOhxaNuyjv8tw17PCEd1Wd7Su83ltlhNTkMDBaMUqIdSh7qe8Ddx+9mDa+JhLAtQ/5+ycwNyZONThmWPbAKOKZdSdF04I2+xaqHZmolmhmgPlc7rvUcOjukeVrCQ+eaHos2kkn6lh7NhqouiQVtBS5dAsjwvoUPA6Y2qnGz6JNIrUSVC5m8Fh X-Forefront-PRVS: 0365C0E14B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(7370300001)(6069001)(6009001)(39850400002)(39450400003)(39400400002)(39410400002)(42882006)(2950100002)(6666003)(5003940100001)(36756003)(50466002)(50226002)(2906002)(5660300001)(8656002)(6512007)(7416002)(7350300001)(189998001)(6486002)(6116002)(3846002)(305945005)(7736002)(1076002)(4326008)(33646002)(53936002)(42186005)(107886003)(110136004)(38730400002)(478600001)(5009440100003)(81166006)(72206003)(66066001)(76176999)(8676002)(25786009)(47776003)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR07MB3094; H:localhost.localdomain; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR07MB3094; 23:F0ldxXckJ+3qlJSC1GTgQsJd+5wIVAo1dBBq7JBnq?= YpmwoDS7YRO5tlrbIpu9eTcISAueYUhB/A5E1gHRUzE66cr3muENE0fXeep7+brW0id+8VnC3/5KkAw5EIQIzyxTfq7NJO0m2m/vDGPPlPeI9ZnddrnF1CKgzEWugysVrIkeSRcwlgt/WSg1yzH/sGPgqdZRCCdjN3NxVsaC0aBR79wSCL4TGMwcCaMzb6WKdgPAPK1nO3KH/zAVjv8Cu7eueRYhabfu1vAk7MVEiWS2Xg7UdITlTwro0NiwRGu3oBGHZWZr/5eZ6y5qUnunKPrf1e/G9Nz6Z6gs58XIV5qjFO6vK6vvh7nhJdLALPRqSeRL8CSmZKqwlP+Y+Wy+mos16oMWzmza6jHr9qq7zCv529tekW+hMTGQOz/HOO4ik18vTMEALM9EISzoFJ8wkYMvZo1xa6KejsF9xKcRnn3O0W7BgZ3FmIq/dWoyqtOcMJwUPFGKIKYYnIcaY6GdDSM50/skoGHpvkF+UST527PjggGvYk7p+EAg23HFBFLAGDMm19S9u9ULLPG/5wDLhhfQgO1qSPpJLEe+Wbjh66eceaAOuRf2PQRGTnXZr+/Jz+xSdVJg+57WYecHVwEzZbXMXYYjGHi5Kl/mIrd8myXWPbQcIVNTmju8uFvz4Uss/8yaXeTZxcozxyDrQQOUxS8gvytr/ER+DenBNu7OSV9hys0DrHlPaavGilDJw6uHmRNeEeAhPGhHJ/xyZq+dtM7ocD4NZReBvvyQqtuvO/Fuuky6VKoVZl3SHDt758oVhdGkWs14V2oUFv87yQFnwahZFfsVUFNUEoHRjEatwqYut7cslOhDwlPoNvi15wyPLYb1uu04ElhvRkP2Nbjv9a35KFVdPSg1IAJ3FKSocZWiyHj7CO4bRDfSPTGfYSRn5R6xpcjdHDSCYAvvAm/VuMtQkYpU3cAItfv8JPg6fX9ZE6UcFlZUqy4bueUfv1bcngi4+WngyBC6G9MaCP0q5iIqE5Yxaf/kPpSM2eLK/DaZcqJzHNSFrMdmZSqI58skwQPbMu/gTYvjWA4Wj89U8GD8l1xzcUl5D1sIcw7MWk882bYL9yUjxlR416OiQJnL1HranoaH+Tph1tDJ1zrFo8w X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR07MB3094; 6:m9y0AUJ7mv/sjNxYSeKn82Cy3o6O+LwCnkr2uDWhWm?= I8NdeZpGmspRHiItfslGZ7SUphtejd8LyVyXLlgfw4UYDsjJ41Hz5bIYIe3yvvKfOBH5tvSwKtm9FQD4RAsCi8k3lDbMc/RNTHkfVqpWxBtQnH2Z7XW+APY/NQAMzTx6QK97Ig3is2LlL4x0mDZd0kFKk8ZgBSu+ZKLeDfJDixLDTe7Pi83n32g9r6r/eiuYjYfvzZNMaLG90xAH9l7Tpaj1USUP05AowhUsIiEj1V5MKPBO4/Qyjg11DLU+8+0r8eWMOvCvvthRQkXnLstUeycvvob0Gsyqv9xN9Dy5oa/RYGmzPDl3p9LhTpogygR1VtARD+iIqaAO1FhLhqXFIBWj9tGfVz2SLT+RvdwXBg+rMJICKsVwLzKlg0EkgJH3wrpIicjc1bMdpBdyZ4tdQzhfeql47HO/W7PEFZGFNGVvZ9QgIYk50seNz6iBH1gpx9D8/FhJxs5LIsPMu+DbkYHcYUPxMRApBN9J7IERNhzNqT/sP/eWDn9WS+3eZa/uWndRpd7hJHkpAzLb0Fki4vwRcREBph3rL4Bkdi9VyTo6n8OZivt/3p25rAcx5xhfq6wl0YgdQrTfbJshOXu6WVIyo26W2ndsKxIVsMQ7G6QgNIMOCqUYRd6SPS2Dic963sX9oFhSDWH1ndDLRVEWHIEG1vzVioPefBLk18LLiERD/2Du5Xep4LSkKleqGiIodHXg2M3hlYqyed7Ixl5NyMCo1X542rOvDaCO7Bz81D2Up1bwcWIX/vewbnRKXW6p64H+sRQpRlTa4kXZyNiT8+58czzEU7+etdOJ3LX6qyH0TVE3mnqfKLMB7L62AQYBCbylttBXWTY1JaTp44EgdsoLv3N9mRqCx2BVyRtT8iF10CP8h3goHt1CMMgjd/yOeRPR7mUpoQQblbj++YEjc5qiQZaL2vxHTPBjFDVFu5CTeMjXEk6c09ak/tlM4U6hc= X-Microsoft-Exchange-Diagnostics: 1; CY4PR07MB3094; 5:2SBE3f8wVuSH5L+2LJKXSEBy3qg3Y3Pgr7sSEcEy1Kyfr4p5nVUcR9xXHkFKmbNj2kzZAXDFFbAUB2UuS10TBc7mTkDryU/tG++bIeiKCEagxmVAb6OzH5LEJMn7vawSHbHzUr6+Lt4RPMSMTbvHlKJNYmMxbr/yAA8fuDJseXWIOb5GE4Sc5nQ3xqz8NzO5t5uLTUNDeJKYTe/zAfhxvAocWFMc/K5j58q7HSuAL2rnOVs18i20ofgxcoitlKe5LLt2PUqGo8g2h1W8A+9vJOiN6KCLW6x+pm42GbenX2FfjcbVYUUt7eaOVuhsBjU/X3bfVKwC5lALuDI/qCYgJKEqgHVD5fvh0hSaPSggP1IOK0VthVACBsgrl3uRSAfzqfZVF4rHwAaqSQ/GJ6DO+yTgk628jyZyMd8fghccoGRU7GREuGRJ6cHT6mP2IW8d1dQcz9FTsr5HSNbDvi9OQyL9qR4MCEYStOmTq9dP34Lde8pTicAX+LIiMNPmd6r6; 24:Vekt4slgyVXitqqVYwnUCqlQ0+6GVqdx7FAqW1A5ZB6zDyhXv9vpQlYbhjbUvfVjwCFuy3oT0caEjTXIOIqJNX0flzasrtWRfaBKfq9Fj5k= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY4PR07MB3094; 7:Bx2HOdMZYH/Wtm7EL9MrqSuyOZDV9LvTcOLMPTy99HyZimCTbqH+XuJ65MgxUbTN/RqB2UMasjhdZfBF6jkkTqcTklCPPY7toDblILfCbqnwRUauOy3gsZWAVNHILWRtKvegAmwENR71AmsbqLHmii9EbtBLn6C3aEK72xQFWoKOQd/JzSEWzQraj0xAUIpYJhSzQ74mtOeXvZkcstPhv3yuHQdfnxSiKd4kpE04CNjtOUoA6WlesU/H7x/oqq1aJnK8ppWia16oyXVtHG7s2TKRuy3GxwEWOzGFFHav9DueHpUc6h9ROXSkU0phs8z4scig5fqJkrjOwpELpW28O8GLNRxv3Izhqk2uidEeNt7Q9n7PNvOzJjBieGfabUQ4OPEfiBi5tEoll9R8SZYBVW7PxDnNkw8yKCYz/CbIvZAOE2ckwblscOIUdnx8bjWdVQt9RoJ0jiLIRwjG6UhX++zs52VFqml1FYnzrUXkOAW0UopWDan49+clWgEEeuZTwBzP6Bsz4C4oQHdW5qKHbfFJGxhN7nyhZxQMlwtyDM9qRX+UHlxL0UiN33/4Wkp931++NOROaiYzR0MFXA2gTvdaax9FAUK5HWgWvCGxL5KQ/37RuzeW3FlymFeRZOkQXmrTnxk8W5JD4eckA5NBJOn0O5li3yZJ7QkdxBRIsmwBFSAOOvFf7CHmWkS3qvPb/BWjsMjFMef2dOixUttNc+hXrhD+Hy8ot0U89vjhUBd+NLXzvzNo4LTOMLOxxVfuUi7oWh92tK3vYH/NdLEMYM54G06vjXo69es2vFPNjZo= X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jul 2017 06:17:25.8663 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR07MB3094 Subject: [dpdk-dev] [PATCH v3 01/11] eal/pci: introduce PCI driver iova as va flag X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Checks
Context | Check | Description |
---|---|---|
ci/checkpatch | success | coding style OK |
ci/Intel-compilation | fail | Compilation issues |
Commit Message
Santosh Shukla
July 11, 2017, 6:16 a.m. UTC
Introducing RTE_PCI_DRV_NEED_IOVA_VA flag. Flag used when driver needs to operate in iova=va mode. Why driver need iova=va mapping? On NPU style co-processors like Octeontx, the buffer recycling has been done in HW, unlike SW model. Here is the data flow: 1) On control path, Fill the HW mempool with buffers(iova as pa address) 2) on rx_burst, HW gives you IOVA address(iova as pa address) 3) As application expects VA to operate on it, rx_burst() needs to convert to _va from _pa. Which is very expensive. Instead of that if iova as va mapping, we can avoid the cost of converting with help of IOMMU/SMMU. Signed-off-by: Santosh Shukla <santosh.shukla@caviumnetworks.com> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> --- lib/librte_eal/common/include/rte_pci.h | 2 ++ 1 file changed, 2 insertions(+)
Comments
On 07/11/2017 08:16 AM, Santosh Shukla wrote: > Introducing RTE_PCI_DRV_NEED_IOVA_VA flag. Flag used when driver needs > to operate in iova=va mode. > > Why driver need iova=va mapping? > > On NPU style co-processors like Octeontx, the buffer recycling has been > done in HW, unlike SW model. Here is the data flow: > 1) On control path, Fill the HW mempool with buffers(iova as pa address) > 2) on rx_burst, HW gives you IOVA address(iova as pa address) > 3) As application expects VA to operate on it, rx_burst() needs to > convert to _va from _pa. Which is very expensive. > Instead of that if iova as va mapping, we can avoid the cost of > converting with help of IOMMU/SMMU. > > Signed-off-by: Santosh Shukla<santosh.shukla@caviumnetworks.com> > Signed-off-by: Jerin Jacob<jerin.jacob@caviumnetworks.com> > --- > lib/librte_eal/common/include/rte_pci.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/lib/librte_eal/common/include/rte_pci.h b/lib/librte_eal/common/include/rte_pci.h > index 8b123391c..ac79040dd 100644 > --- a/lib/librte_eal/common/include/rte_pci.h > +++ b/lib/librte_eal/common/include/rte_pci.h > @@ -202,6 +202,8 @@ struct rte_pci_bus { > #define RTE_PCI_DRV_INTR_RMV 0x0010 > /** Device driver needs to keep mapped resources if unsupported dev detected */ > #define RTE_PCI_DRV_KEEP_MAPPED_RES 0x0020 > +/** Device driver needs iova as va */ > +#define RTE_PCI_DRV_NEED_IOVA_VA 0X0040 > Maybe not a big deal, but using NEED tends to say that the driver cannot work if not using VA as IOVA. If my understanding is correct, this is not the case, the performance will be poor but the device will be functional. Maxime
Hi Maxime, On Tuesday 11 July 2017 02:39 PM, Maxime Coquelin wrote: > > > On 07/11/2017 08:16 AM, Santosh Shukla wrote: >> Introducing RTE_PCI_DRV_NEED_IOVA_VA flag. Flag used when driver needs >> to operate in iova=va mode. >> >> Why driver need iova=va mapping? >> >> On NPU style co-processors like Octeontx, the buffer recycling has been >> done in HW, unlike SW model. Here is the data flow: >> 1) On control path, Fill the HW mempool with buffers(iova as pa address) >> 2) on rx_burst, HW gives you IOVA address(iova as pa address) >> 3) As application expects VA to operate on it, rx_burst() needs to >> convert to _va from _pa. Which is very expensive. >> Instead of that if iova as va mapping, we can avoid the cost of >> converting with help of IOMMU/SMMU. >> >> Signed-off-by: Santosh Shukla<santosh.shukla@caviumnetworks.com> >> Signed-off-by: Jerin Jacob<jerin.jacob@caviumnetworks.com> >> --- >> lib/librte_eal/common/include/rte_pci.h | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/lib/librte_eal/common/include/rte_pci.h b/lib/librte_eal/common/include/rte_pci.h >> index 8b123391c..ac79040dd 100644 >> --- a/lib/librte_eal/common/include/rte_pci.h >> +++ b/lib/librte_eal/common/include/rte_pci.h >> @@ -202,6 +202,8 @@ struct rte_pci_bus { >> #define RTE_PCI_DRV_INTR_RMV 0x0010 >> /** Device driver needs to keep mapped resources if unsupported dev detected */ >> #define RTE_PCI_DRV_KEEP_MAPPED_RES 0x0020 >> +/** Device driver needs iova as va */ >> +#define RTE_PCI_DRV_NEED_IOVA_VA 0X0040 >> > > Maybe not a big deal, but using NEED tends to say that the driver cannot > work if not using VA as IOVA. If my understanding is correct, this is > not the case, the performance will be poor but the device will be > functional. > Agree, How about renaming to RTE_PCI_DRV_IOVA_AS_VA, make sense? Thanks. > Maxime
On 07/11/2017 12:35 PM, santosh wrote: > Hi Maxime, > > On Tuesday 11 July 2017 02:39 PM, Maxime Coquelin wrote: > >> >> >> On 07/11/2017 08:16 AM, Santosh Shukla wrote: >>> Introducing RTE_PCI_DRV_NEED_IOVA_VA flag. Flag used when driver needs >>> to operate in iova=va mode. >>> >>> Why driver need iova=va mapping? >>> >>> On NPU style co-processors like Octeontx, the buffer recycling has been >>> done in HW, unlike SW model. Here is the data flow: >>> 1) On control path, Fill the HW mempool with buffers(iova as pa address) >>> 2) on rx_burst, HW gives you IOVA address(iova as pa address) >>> 3) As application expects VA to operate on it, rx_burst() needs to >>> convert to _va from _pa. Which is very expensive. >>> Instead of that if iova as va mapping, we can avoid the cost of >>> converting with help of IOMMU/SMMU. >>> >>> Signed-off-by: Santosh Shukla<santosh.shukla@caviumnetworks.com> >>> Signed-off-by: Jerin Jacob<jerin.jacob@caviumnetworks.com> >>> --- >>> lib/librte_eal/common/include/rte_pci.h | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/lib/librte_eal/common/include/rte_pci.h b/lib/librte_eal/common/include/rte_pci.h >>> index 8b123391c..ac79040dd 100644 >>> --- a/lib/librte_eal/common/include/rte_pci.h >>> +++ b/lib/librte_eal/common/include/rte_pci.h >>> @@ -202,6 +202,8 @@ struct rte_pci_bus { >>> #define RTE_PCI_DRV_INTR_RMV 0x0010 >>> /** Device driver needs to keep mapped resources if unsupported dev detected */ >>> #define RTE_PCI_DRV_KEEP_MAPPED_RES 0x0020 >>> +/** Device driver needs iova as va */ >>> +#define RTE_PCI_DRV_NEED_IOVA_VA 0X0040 >>> >> >> Maybe not a big deal, but using NEED tends to say that the driver cannot >> work if not using VA as IOVA. If my understanding is correct, this is >> not the case, the performance will be poor but the device will be >> functional. >> > Agree, How about renaming to RTE_PCI_DRV_IOVA_AS_VA, make sense? Yes, and if one day we have some hw only supporting VA, then we could introduce RTE_PCI_DRV_IOVA_AS_VA_ONLY. Thanks > > Thanks. > >> Maxime >
diff --git a/lib/librte_eal/common/include/rte_pci.h b/lib/librte_eal/common/include/rte_pci.h index 8b123391c..ac79040dd 100644 --- a/lib/librte_eal/common/include/rte_pci.h +++ b/lib/librte_eal/common/include/rte_pci.h @@ -202,6 +202,8 @@ struct rte_pci_bus { #define RTE_PCI_DRV_INTR_RMV 0x0010 /** Device driver needs to keep mapped resources if unsupported dev detected */ #define RTE_PCI_DRV_KEEP_MAPPED_RES 0x0020 +/** Device driver needs iova as va */ +#define RTE_PCI_DRV_NEED_IOVA_VA 0X0040 /** * A structure describing a PCI mapping.