Message ID | 20170711100141.3950-1-jerin.jacob@caviumnetworks.com (mailing list archive) |
---|---|
State | Accepted, 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 35840532D; Tue, 11 Jul 2017 12:02:41 +0200 (CEST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0065.outbound.protection.outlook.com [104.47.36.65]) by dpdk.org (Postfix) with ESMTP id BAD1D377E for <dev@dpdk.org>; Tue, 11 Jul 2017 12:02:38 +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=BmQGz6K3wdZrTGAmGo7bYepDekf2x4biGqI0AITl7ps=; b=l3Tw0Q7olqaplw349Lqb+1jVvQAquTkXFe3ht6mDsCyCe/vbLYsPIfPc+DDMB5BDb8stuWsJd7Ey7RYbB35lDQYLu9Q9JtO42OOTC1RIWD6S4fkfkZqUd/tK5aCj7aYR0+vxkKOKjJENbL7uEZ+njrXNATgcCdlBf2qi8dOapFM= Authentication-Results: dpdk.org; dkim=none (message not signed) header.d=none;dpdk.org; dmarc=none action=none header.from=caviumnetworks.com; Received: from jerin.domain.name (106.201.60.201) by BLUPR0701MB1713.namprd07.prod.outlook.com (10.163.85.14) 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 10:02:31 +0000 From: Jerin Jacob <jerin.jacob@caviumnetworks.com> To: dev@dpdk.org Cc: thomas@monjalon.net, olivier.matz@6wind.com, stephen@networkplumber.org, santosh.shukla@caviumnetworks.com, hemant.agrawal@nxp.com, bruce.richardson@intel.com, shreyansh.jain@nxp.com, gaetan.rivet@6wind.com, sergio.gonzalez.monroy@intel.com, anatoly.burakov@intel.com, Jerin Jacob <jerin.jacob@caviumnetworks.com> Date: Tue, 11 Jul 2017 15:31:41 +0530 Message-Id: <20170711100141.3950-1-jerin.jacob@caviumnetworks.com> X-Mailer: git-send-email 2.13.2 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [106.201.60.201] X-ClientProxiedBy: SG2PR04CA0149.apcprd04.prod.outlook.com (10.170.139.33) To BLUPR0701MB1713.namprd07.prod.outlook.com (10.163.85.14) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5d0871b2-7563-4fdd-304c-08d4c843f4dd 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:BLUPR0701MB1713; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1713; 3:IfXQV6kWc9R7FOIMWylrujre+2NF7b3shCIco5vzujfTpljq1wSU2lK3cUAzKPxYp6KDPtYSjVZmFwF5zWnXbds7yOynLqeuuRaNRndcwMdElb04XTgargJJzyv+mkGV4Vb87LR27IFgEprHKbyxv0xLTECQqR0ck8C39aBYzt8PBeTCMr+9dEUCEsqlz9DJTjc09LSqfIEOWqsLQkt0YavcDEDWN2e8dymKMy+rWROdBlETn4uz4lf8eB3SEyNPRqn7xCMF3lRjLv+8xSWtTj29PVYdWMwJ65R4d0mCON0TVcfcDk/+c0aGOOzP5ds7xGeqSdMN/UkwW1d3cGgitfchMZyL6eQnng9V8L/MtZcE2DGdicEnPGjMzzf1E7BtAtbCvJbeoORS+ZO8Fstj4DGifRW+f4vjuwyEFGCmMk5faQTI0Tx6GT8wFkAWdtgpK6CJTcI1bzb5/bRWS30b4VHqUBpJIGJv5uEj+1q+8+mJHu7Rn9XcWNwGwALPFNDIFbhPkRpYglDMAHG3bUbMo/TlWiss+HNIteHVKUfphBzGTfwQKITHM5c9qbVxFZ5vOoj4At9wZp9NOu8TbVgF93c2OfRX2Wfos2QHB6zKT0RnuqU608D9AdNuyJDwu82Jx9ROi2EihLVPbE/vdKjuf25z6YcvwSE/MSN8jXXuoMl5lD3hYCL3iZTnAyUl/OHP7yUVqa2eXTKK2Mrbb2uWTQE8jO8WHp9oJlAx7C6kp1U= X-MS-TrafficTypeDiagnostic: BLUPR0701MB1713: X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1713; 25:ddAYRlZXjnuUid8FDzBDaiGFoVHBYmuyoASx+3NqrLFG/IrS91Y4QCOFLLZgwZmtOiHW1pobOMFOJRYR/eGmV/RI38MJnQaFExMmC980qUs6uI7iPXkMzYbM6n+IfGl22j75kbhpKs4/hCchF71/33h2ugB8EWAKaxTzY/eP1YNf2EL+m147ZyfG1e6COzVTYVMFDrbg+1F6Sc1RbYpxBrbZEQkXEyikHrGFfv6p/iNt+OuOYcBCydB2pDYykZ14RXUtc6yniW6yw/UiJX+TPTyLcRaIJ8lBQwTTA7SyROdRiWjp6OWYB6DvTrqE2EDq4B5vRYa0ZDKOSGIoypmthh+X/Ks6+NygbFR4kEdfqVea2grWtMjPSSCoXfWzYSqklMvGFBjQLrXFj1DV5saf9NwqWoEh7W4nr0t8D/8sVpMLtmZy46UqaCs34q3DyOQrozYYxMOBFSsnmpvuyzZ4vx0a9QlsuBInQ66tNsGizErMl7UuNFhr0zeo5A3MfqD+9+oiyQ19mXnoby+DV7FcjWm9uikZMV/JcXDZaOCr1HXVv1YoAuhXxkcpBA4yHKmNVcOxW12rUZyfYF0R/vWIUAYVehp5dz9cN43n0Xc97xJLU7j42OFTgdjwHaEhZuWe1yWjRbA8gReq/zqrV16KJJmjNsBRLNHTIijXbsM80oecQJYesvy7ua7jRZj44UZ9i0hserpraOq/SW54RUgdyePyGcghofhZXt/v1IP1ccHnxbtnPIImK5Ow9M4yB8MZUmoAT7dMDD7UPu9MvN4KEOypfJD4oiVmnd3P89mOwGVtLsDVESfflmNVHoEb4q5mGDOUdvL3nCDUEfVfRQInytnmnV/wtWwnMW1pOE4TYFU2+pF25zqobu5r/q1lnO3S41yxnUQHC6OxIBU/FUnB8t+xF13KlkzRmPOJ7z5qjW8= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1713; 31:VwUmU0l3+xgA/gXLjZSXpanmhJrtEtAKenjSjZv3T4LvQpqgKHWWfvSSW2TopsPZqO+kxr8MjG1XcsY3d4gOA1cVehwQrULpbUJfxe0pIzpY1BH5/WbgbjIkOJXk9cF/sfvNHOZ5XgP0ipyZqlIVo3Bq7AdX9n2DQ2FHdgTObYPMac1iXSl6vZyuncGA6PBczlPQ+DNeIdCESpflFxCw4XxoHpjwm6N2oeopMbR3tM9X/ld75mOAdDPQoUWnWAZB6OfqRw2BXlKoaS9bOFvRyLtll8RkKE/7Sl5Woic0LuAhr9vPJAXjkO0gswqGloevYTmvLc+j1DSRfKLh8uwak9luOUCBYv4QQ9Tdg7lHFKXqNrUHZtHTlgtanbZGokY8Q7lpheEg98fVgiWYldXu8IOznd39yrXiQpdMMQuBfNT+6vIOIM+htTg4cdCQ5iCYJ5TQC/rS88uGaCweonwPhUFnsf5YzYHnqy5wUIB+fLnM3sMScz+QVAzDy84IWixWG8fkRCMRk2LYGhngyCoAaqVi9QgTZmYLzUiF86mlPhW9mXqdO9FEUk5dxiJKxl8MwG2qy/j78q/cEiI0LBhIj98/UPphPuOlgDjtw7R1pzKuKAbqYtIH/AkDOwcdkBKc0iSHB2Yss9Pfu/BQLmGh7d/MI7bAi6mGbm5t5Bz0Ik0= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1713; 20:HxXUBPOYudUxeciMcAKHCN0FfRDUdmbcclUgau7NkFEcI22p4FvoXWFocVVcbgDiFB+TCR4njsoig38KIGvjDF9pXoLXBDDC+jqrIuJWpVsCnT2r/qwhYxCrVwCkNfBR2Y2mGGbycj6kUSiLJhYMVubIT7Dcy8vwbZuhDCWjTn4QsY1Ka3IUontiGB+MskZlBbKl364VkNoxfmZUr+8ODkHy8k2AI00DNhZVBGt3WkFl4wAWzQrbeG735FlRG4Gz8QDxSTMq6RR6Th3ErHq2jVhi5CY9VYkDGPDgRvdRgZ1Y0ses6EXnQahlp8KVecxeR7mVDJe54UdnFmi+E2udaO5/pRqLMJyNPuR01e2xY/sB+i0bcfoeErOz84b5P1GeD2ISJQy2athhyqzsSdPoXXXQeiU9lvQ0Y9RuujhB80z6wbaF2ybXEbnq8fTFdY0l5vy0JZZmBUIObkbQEvavMePIq/tkyJRxq8uAwvqxHB8pdncX7uHqrY1OgJGPUFWBRv62BlmSzFP8taVjriIXrmmuJuQjFDnZ9KGrJlptvh77S6riWHT4CwLzyXkAS0Z8kAkYwkawRZXsl7JG36n0WXwZVQ6rN3qv3b7VY6cmSpY= X-Microsoft-Antispam-PRVS: <BLUPR0701MB1713CA753BFB7ECA3CE57D01E3AE0@BLUPR0701MB1713.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)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(6041248)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0701MB1713; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0701MB1713; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0701MB1713; 4:eogYBuiimoyybaKBXKdbV3vWgJJD/lkygx0EQeb5?= TSmTjUohg9u+ZL4Sp4uMUVZGluMtIvIpW6L1K+mfxexQ8TiXzZThevchECZpURWvxZQ/RZycUTCUY5a+g4h+YbmUBbKcIjAqNchSbKt/vwHwynMA+tkQzD1BCCJQrwOvdwWcIpL4Nb0/XnAUlZG7CAVJMsamf1HigUtO0OHAIyh60L4Ra11PW2uVuQA2gebBeMYtroQHs4NJ1Awkkyul5x1FDumkbxR01y4P4FinNn13mRYBrS2b+6DmY6HjNyxOOwd+wjD++lBwqVwIHFCVpT6qF4yTviIwiMWX/H6ckoobaQayxhoRewPa26E5zf5bRzWniiFHBieRPRXzqpNjZztFGvnxMXprf3vyv1R2joWPhHlP4rLaiAmLegjtypCzldSowFuSJNUrKFwLvxMa0PSp2AtZ+W+wx576FulyWfOTd+Fy2gH8R/cQyKsuhaEdL0NtGuSREUjgLu+/j1maNV+YQKQaXeAOwNNBCfpoAyZbvb8HY6926gGcTtWJOesXAhEtkbXbyrR4QVa6To1N0mNcrPJyAaacsXfA+WuNVGhRCWjkdYzOzY2MbNekX4IgrvVXWstXUzvgmNiIY552pP76VwRqXwRzQ7uIsu1TFAvlnRLES1dR/uDesNRPrMcdoJYysR16vv69OIUaorBQXfnNfH5IBYVYYYlAADXcHcXszmJ1HMMXdB/WosbeHgsPELIHWtfSsw9C3+f3JfQvN625Gs8AtHPDlOoQw9ZE29K7ociNGIQADDIsbHNLNovunwLnEf1w9ZvXej6LSz1pYMT5h7CTZFfrvQoM4E+hpJDQq8AJzmbAvCglAa34PzfFj4z25AKK11U004qxsbhYnxQjpTEBAYt+QuF4KIXM5sbZSkzxSzngPxmhST6vEiG12ig5W6rbhm6iHG/qRnwewfTTGdtHsaMLEbkYw7ANbmqd0JmqoA5JA4s+Iap0kZWxepWP08OJm61WhnZqgZRDFJBOUf7Rm2+lvy2UqXpa8PxVldYxHInvP0bql/U8xu4o2fs342Xt4q6zzlb887OP64msRls193JstypFYJL87yWbUkFAGepF15Mpri1hgmVNUdMzsr5iYaj3dTreRAjiIuC3zfLvNeEX9ukt/Qdib6Zf2GG/aLErWYTpob/sbL8wx9D9UAdGvheN9Rya2NmEvLiO X-Forefront-PRVS: 0365C0E14B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(7370300001)(6009001)(39410400002)(39400400002)(39840400002)(39450400003)(39850400002)(5660300001)(15650500001)(6666003)(53936002)(110136004)(38730400002)(107886003)(50226002)(2420400007)(53376002)(42186005)(5009440100003)(305945005)(50986999)(42882006)(7736002)(6916009)(53416004)(6506006)(6486002)(8676002)(36756003)(6512007)(47776003)(189998001)(1076002)(8656002)(48376002)(7110500001)(10710500007)(66066001)(72206003)(33646002)(4326008)(2351001)(3846002)(7350300001)(2906002)(50466002)(7416002)(25786009)(966005)(478600001)(6116002)(6306002)(2361001)(81166006)(5003940100001)(217873001)(15398625002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0701MB1713; H:jerin.domain.name; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0701MB1713; 23:CgQFfazo7zvqhUw1HYgeMgvJE4tld4BkgjG6x8j?= OkkNyUHeOXBrOjSrGrGAa76FoD/eIbU36T40FYRrNu15+nWcraNBzTuORVlBq1x+FsmKctqRt3pksoViDDCitRAu43jhuO+oW3TR6LW4CejiXWXMgbaC5ldZbkFmoFbOMGu6TGPrHiumDgbbBqBa2PSw4ZaKiGh9vFdnwjT/BoFtx7Dza8oEJPnSgIE7kZSJTHzxXvNlujbToTtjSnF+DtPvnKxJthh1xyWDWW5iEwb42hH6vQHJaVM/j0XAqOB4MICcCxicePJ7cfXddGIMTI299SVY74lK+vp0t0iljn9p2D7B6fRpd27/VhUKY27TR2EGwgZhUJQD8H9HC0uTfIne9R88PmGkGhVV3FuX1IUZY1ZllVqGnc76geqb/X9yBIw7vaeswCFT/0aOxY+6wiNd9L44tTbXi0K0CFfP8uHo4lJAzNcAWrz16wz+b7gx94PfbpKv3MRtd9CiSdnzODmx3tFGwTBvERIUHBWMdbssVTZSmlvFgeJ82OcZx2ijhRpiDbMxPVWCwn+vNZkrd+Q4dRNW8DrrR9NIEIPplAC2FJ04EkfMjneE9F8MOFF/M4u3ZhSSreBKJ7mE5foMIui0fzaqxTQwsEG0MXBpBzu6WpWFFqk2FdG8PjEbKly5ykDf7W0KcIxZ4ZAH58T5tW6kYZ2a2aFI6kbn957ocEeGRqTL3G1fQ8Utk/hmGYd4IPsqGa+u+ZCEbVNHkoIOOmUb8fbCjQ5qL86Dl5xnI8slJfldoL/sXuLhKWFYE6zJ+OyNCTuGU/j9lGkGCd89C9B31JmhOvtQyoCVW+QpbEorRPUK6NDMiGl0/CyzSQ7HDBrGUtHoYyQ4eWAfZNFB6S+b4KtGdnJpQNqA3E6nBweTxvsn8ruOHWnKmkOxGIknJMnpKDoaN3zi06SJNwbtOcbpae9TwsPoH5rNEq6XytjwPfqXzByVKk1zfpKD4VjCgoS1Wgbro6/rhWa81BfIkcRaDv0lJL1Hrnxn4CZIsIXW9ZX798kwbZDY54rxGNFw9ifcWc9VLbdm5dB2iF6i9xP8CaneexAE1JmUjkJq4GDe+YLh1MbfcNa2336YsxzaImceEFVwWRGNwhg2Ib+tHiR0bLrxu/ZIJE7MqiOkmUfW6sak5g6mVeiXNvZPDVgH6++MIo52NmLHxodQJgyLUkYS8+sfWZFjGrpqWVVIskMVQTSf3EH2xDiLpmWkZj+zOBtrwrXJm/dVEH0/M5BYOglq6zV7bvIYpA+0ojYVRilF7trxMZHseGeGsRp0W3aSJtpucXCn7RNk9rZOngrFpl3xOAAflpdvhC1O2Bk5JkiSOKwAieLHtdMm1n+J55/tS2J11+ykdbXSqbMyZdawbh5MAMvFS0TrqRc9prIKBjTLlcq3ZITEc2GIPGCmRNdZczUE= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0701MB1713; 6:M5ccFgMkSBHK4QlIOXVmObav/rckhE048xeVgIxV?= 1xydUg9NziVglmuSB58Fu5WoK5fNr+AHKYhNWZG18g8vbeLLwth9XTYls4V8qJU54IbQrIOWnAl+JF1bU1Igff6s9LlcxVEhUEtV3fkzt3S1rK9Cm5h9UnKqi85xPaaJnXYbaU6JfNOoXaGhOpfHsGjUahZWIH7tuC/ejT3bPRogrmYrzycL3shxFtqt13/GEz78TOpCO4gZrFDa7kgsPUyfmlqi5y9RYiBRjDLv4kQW6faUVsvMed0oSPvNvmwTXk/AJdu/W2f2LvsHbSDhRYCqAHbz8X6K6tGarnJp5Vo7HslJW75HhgpQXcKd4I6oa5yqvCo9NyZ5i88VXhMlQ3KnYpmv42l5DhdVZt/WrMOzQfm6ODmN2Lf6Y54Ez/7ZC+BSBvb4H6dV6EcpFw1PRLHDbVSjQ3C12THiKiMRaaUfMWmBKxy72a8AttOnsKXFc4By5MPYL2DQGM4Nd1+JoPdHZXln344qqCbpoyMVPgNeGXuIoRxjsoUF/jOQt/p7icS9jjL+fXHtSVoyHQvhGYVNCbNpFmNZB/kgjOaSR90vFsuTpE4+yhTS0YKY/LN8NQXqkDEX3avPnjDlI3+irPH0te4s4RSwxz2eet70bG66YJCa0f1RKD4ylQnlGrId2B8StHxwog2+/tusSBVPqI0rNue8my9ovTuVGevlMQwouqfQvMZLfxqOidbmu4xYN1sw3VEGxPBDqUS75q374TeVqrUKop+rS8WhR0aJzW5YyVwzvkHlp1jSs2efgWZQX2pPKrqND+s7efsKW1ykfxqrP4OAbYCILFdMeewcuZk5BU1d1eglKZah9CZoFUf9eBLIilj2Uh2kiHkZF4q5CmAwRQJvqvZ1VkK5YhHCPSV5Mz2c1ObeLGE2qkbxIR9DfMHBI6YGle27LRRjkIWSuqmuHgR2y0zr2LZkhgb8m7ZInRSZcf2lABty5s/PaC+WWZU= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1713; 5:R2VDnXP1JEKSUS31MfSdKRGVQE0beGRW9R9zyvH/QyDvozOb4cO8KE3Ld+lYGvbkWys6HTojxU5uqWRkpYGQGqkahdSml5Mb/U3uFmUB/FWgXKpIoFxr8cR2UG25zFUMp5vdqChShlh3tFvxLZW5QHTNbUnZUbkKX+g3azAxWK2HBQqFv62gzlvnDQIgOCnbS+XhnDcpQunti2wwOjAauBdwiPuYqlpIOmDmkf0QxnU5mFpFXHcb0ymUv63cT1DjAH3b/p/D6jPRtJY6Gopfk6RsrtCg2tSXNuHW6joKr+/UWRc1p5JRyizMk4gn2UC5hrvu/thuXZWvPYnSqrmUVKJq97vAOo9ce3SKodMQYIsgiogC5wJ5jXhHI4Zmti5N/wOLT9xoajingV5Bgwyyo0nKeqFtQe/mZY4IY6mNj5YvHnmdgotDIxnpvHI7aLOvJSNH25VZHrveKFjwEdbr77LKF+ISP6Yclxs/Gtp9OWhUV83Ju/pEv+sqvfB1WJPA; 24:HHfLNdqpfqvwilBjEsyQys034ZahUlXpwLlDY0m61xBYnYPIRFZhRV+lSCpZ2c6TaQNaBFvlEo+ywtf59nWQRKhFU/faQBj72hbNmd2wEkI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1713; 7:Ri/0fX7/lTjczeAQ/KsxHG3Z00go0rnZ53wmO0p1y09WFFYyI17VYXxMk82PTt/+OG63tzQFboZMu7RowYmdgQVmCTAXo+9d/md17ooJKf2m25mJIU2mqOKqXUJYpXRRfIPDGUnk6gMPX22LVxKwbAe70hFYz8dqnidqJPtBhyC2inphiROeYzYaf2x6LySXVcJN78xMokvUqQHQR91bjNhLbL1Bhwha37oNV4O1Enk/BgrkU+Zc7Stps8Q1LqMzd4Suhu4EPo6tJwGOfsYX+18luPQCavMI2hSzNyMGWQNblD4FqF3X5P780b10edBwN8+Y3QdsYZofzFP+uBuCdAHo/wbmVjjUmEyQAYFi7oc7nQ9FOF6a9JxGhDuwoydBTtD3/oLHcHJpdcMMxHKClcnUzyQp4mi+1n6n1yV0NPt4UflU9cTH8pEwhr4Tk8bkmCSwcCn2B/tAGEUpfbU/yvNXQ8QR6GfJPNK1Agbu2llFqHnWBQqTKVhckgUSIAYk4EPSl/3tEVDwGo0Pjy/ANHOVf9CHL8dIC8tZnhyq59sq3YsI9OK8ROl8G9JH61c3mKcWMJlJTokqhQ3dqvJtYCyMgcnZJkDwn9qLri+GdcnUL95x4kIlOuKAGVMpY21JeNGidIEuYxv5SD/rsLf7av7FPnc/ysfg01vaSVZivDLN3NdOJnzfNfINnyyFKjy0EBd87Emox8DRaOiCBOL7aioNMaJHWGst1DBJT8Iu+8whry0Ka4FKiO/xl78af4hHOyL1dKqmXAPYpl99aJxfs/OBDxgIKrWiXBDALxNtivQ= X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jul 2017 10:02:31.8953 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1713 Subject: [dpdk-dev] [PATCH] eal: add notice to make DPDK IOVA aware 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 | warning | coding style issues |
ci/Intel-compilation | fail | Compilation issues |
Commit Message
Jerin Jacob
July 11, 2017, 10:01 a.m. UTC
When we run DPDK on guest or VFIO mode on host,
the dpdk library or device will not be directly accessing
the physical address. Instead, the device does go through
an IO address translation memory management unit. On x86,
we call it as IOMMU and on ARM as SMMU.
More details:
http://osidays.com/osidays/wp-content/uploads/2014/12/Final_OSI2014_IOMMU_DetailedView_Sanil_Anurup.pdf
Based on discussion in the following thread
http://dpdk.org/ml/archives/dev/2017-July/070850.html
We would like to change reference to physical address to more
appropriate name as with IOMMU/SMMU with
the device won't be dealing directly with the physical address.
An ABI change is planned for 17.11 to change following
data structure or functions to more appropriate name.
Currently planned to change it iova as instead of phys
Please note: The change will be only for the name and
functional aspects of the API will remain same.
Following functions/data structures name may change.
This list is based on v17.05-rc1. It may change based on v17.11 code base.
typedef:
phys_addr_t
structures:
struct rte_memseg::phys_addr
struct rte_mbuf::buf_physaddr
functions:
rte_mempool_populate_phys()
rte_mempool_populate_phys_tab()
rte_eal_using_phys_addrs()
rte_mem_virt2phy()
rte_dump_physmem_layout()
rte_eal_get_physmem_layout()
rte_eal_get_physmem_size()
rte_malloc_virt2phy()
rte_mem_phy2mch()
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
doc/guides/rel_notes/deprecation.rst | 7 +++++++
1 file changed, 7 insertions(+)
Comments
On Tuesday 11 July 2017 03:31 PM, Jerin Jacob wrote: > When we run DPDK on guest or VFIO mode on host, > the dpdk library or device will not be directly accessing > the physical address. Instead, the device does go through > an IO address translation memory management unit. On x86, > we call it as IOMMU and on ARM as SMMU. > > More details: > http://osidays.com/osidays/wp-content/uploads/2014/12/Final_OSI2014_IOMMU_DetailedView_Sanil_Anurup.pdf > > Based on discussion in the following thread > http://dpdk.org/ml/archives/dev/2017-July/070850.html > > We would like to change reference to physical address to more > appropriate name as with IOMMU/SMMU with > the device won't be dealing directly with the physical address. > > An ABI change is planned for 17.11 to change following > data structure or functions to more appropriate name. > Currently planned to change it iova as instead of phys > > Please note: The change will be only for the name and > functional aspects of the API will remain same. > > Following functions/data structures name may change. > This list is based on v17.05-rc1. It may change based on v17.11 code base. > > > typedef: > phys_addr_t > > structures: > > struct rte_memseg::phys_addr > struct rte_mbuf::buf_physaddr > > functions: > rte_mempool_populate_phys() > rte_mempool_populate_phys_tab() > rte_eal_using_phys_addrs() > rte_mem_virt2phy() > rte_dump_physmem_layout() > rte_eal_get_physmem_layout() > rte_eal_get_physmem_size() > rte_malloc_virt2phy() > rte_mem_phy2mch() > > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> > --- Thomas, All: Any objection on iova aware deprecation notice?
On Tuesday 11 July 2017 03:31 PM, Jerin Jacob wrote: > When we run DPDK on guest or VFIO mode on host, > the dpdk library or device will not be directly accessing > the physical address. Instead, the device does go through > an IO address translation memory management unit. On x86, > we call it as IOMMU and on ARM as SMMU. > > More details: > http://osidays.com/osidays/wp-content/uploads/2014/12/Final_OSI2014_IOMMU_DetailedView_Sanil_Anurup.pdf > > Based on discussion in the following thread > http://dpdk.org/ml/archives/dev/2017-July/070850.html > > We would like to change reference to physical address to more > appropriate name as with IOMMU/SMMU with > the device won't be dealing directly with the physical address. > > An ABI change is planned for 17.11 to change following > data structure or functions to more appropriate name. > Currently planned to change it iova as instead of phys > > Please note: The change will be only for the name and > functional aspects of the API will remain same. > > Following functions/data structures name may change. > This list is based on v17.05-rc1. It may change based on v17.11 code base. > > > typedef: > phys_addr_t > > structures: > > struct rte_memseg::phys_addr > struct rte_mbuf::buf_physaddr > > functions: > rte_mempool_populate_phys() > rte_mempool_populate_phys_tab() > rte_eal_using_phys_addrs() > rte_mem_virt2phy() > rte_dump_physmem_layout() > rte_eal_get_physmem_layout() > rte_eal_get_physmem_size() > rte_malloc_virt2phy() > rte_mem_phy2mch() > > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> > --- Acked-by: Santosh Shukla <santosh.shukla@caviumnetworks.com>
On 8/4/2017 9:11 AM, santosh wrote: > On Tuesday 11 July 2017 03:31 PM, Jerin Jacob wrote: > >> When we run DPDK on guest or VFIO mode on host, >> the dpdk library or device will not be directly accessing >> the physical address. Instead, the device does go through >> an IO address translation memory management unit. On x86, >> we call it as IOMMU and on ARM as SMMU. >> >> More details: >> http://osidays.com/osidays/wp-content/uploads/2014/12/Final_OSI2014_IOMMU_DetailedView_Sanil_Anurup.pdf >> >> Based on discussion in the following thread >> http://dpdk.org/ml/archives/dev/2017-July/070850.html >> >> We would like to change reference to physical address to more >> appropriate name as with IOMMU/SMMU with >> the device won't be dealing directly with the physical address. >> >> An ABI change is planned for 17.11 to change following >> data structure or functions to more appropriate name. >> Currently planned to change it iova as instead of phys >> >> Please note: The change will be only for the name and >> functional aspects of the API will remain same. >> >> Following functions/data structures name may change. >> This list is based on v17.05-rc1. It may change based on v17.11 code base. >> >> >> typedef: >> phys_addr_t >> >> structures: >> >> struct rte_memseg::phys_addr >> struct rte_mbuf::buf_physaddr >> >> functions: >> rte_mempool_populate_phys() >> rte_mempool_populate_phys_tab() >> rte_eal_using_phys_addrs() >> rte_mem_virt2phy() >> rte_dump_physmem_layout() >> rte_eal_get_physmem_layout() >> rte_eal_get_physmem_size() >> rte_malloc_virt2phy() >> rte_mem_phy2mch() >> >> >> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> >> --- > > Acked-by: Santosh Shukla <santosh.shukla@caviumnetworks.com> > > Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
On Fri, Aug 04, 2017 at 10:55:25AM +0530, Hemant Agrawal wrote: > On 8/4/2017 9:11 AM, santosh wrote: > > On Tuesday 11 July 2017 03:31 PM, Jerin Jacob wrote: > > > > > When we run DPDK on guest or VFIO mode on host, > > > the dpdk library or device will not be directly accessing > > > the physical address. Instead, the device does go through > > > an IO address translation memory management unit. On x86, > > > we call it as IOMMU and on ARM as SMMU. > > > > > > More details: > > > http://osidays.com/osidays/wp-content/uploads/2014/12/Final_OSI2014_IOMMU_DetailedView_Sanil_Anurup.pdf > > > > > > Based on discussion in the following thread > > > http://dpdk.org/ml/archives/dev/2017-July/070850.html > > > > > > We would like to change reference to physical address to more > > > appropriate name as with IOMMU/SMMU with > > > the device won't be dealing directly with the physical address. > > > > > > An ABI change is planned for 17.11 to change following > > > data structure or functions to more appropriate name. > > > Currently planned to change it iova as instead of phys > > > > > > Please note: The change will be only for the name and > > > functional aspects of the API will remain same. > > > > > > Following functions/data structures name may change. > > > This list is based on v17.05-rc1. It may change based on v17.11 code base. > > > > > > > > > typedef: > > > phys_addr_t > > > > > > structures: > > > > > > struct rte_memseg::phys_addr > > > struct rte_mbuf::buf_physaddr > > > > > > functions: > > > rte_mempool_populate_phys() > > > rte_mempool_populate_phys_tab() > > > rte_eal_using_phys_addrs() > > > rte_mem_virt2phy() > > > rte_dump_physmem_layout() > > > rte_eal_get_physmem_layout() > > > rte_eal_get_physmem_size() > > > rte_malloc_virt2phy() > > > rte_mem_phy2mch() > > > > > > > > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> > > > --- > > > > Acked-by: Santosh Shukla <santosh.shukla@caviumnetworks.com> > > > > > Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com> > Acked-by: Olivier Matz <olivier.matz@6wind.com>
> > > > When we run DPDK on guest or VFIO mode on host, > > > > the dpdk library or device will not be directly accessing > > > > the physical address. Instead, the device does go through > > > > an IO address translation memory management unit. On x86, > > > > we call it as IOMMU and on ARM as SMMU. > > > > > > > > More details: > > > > http://osidays.com/osidays/wp-content/uploads/2014/12/Final_OSI2014_IOMMU_DetailedView_Sanil_Anurup.pdf > > > > > > > > Based on discussion in the following thread > > > > http://dpdk.org/ml/archives/dev/2017-July/070850.html > > > > > > > > We would like to change reference to physical address to more > > > > appropriate name as with IOMMU/SMMU with > > > > the device won't be dealing directly with the physical address. > > > > > > > > An ABI change is planned for 17.11 to change following > > > > data structure or functions to more appropriate name. > > > > Currently planned to change it iova as instead of phys > > > > > > > > Please note: The change will be only for the name and > > > > functional aspects of the API will remain same. > > > > > > > > Following functions/data structures name may change. > > > > This list is based on v17.05-rc1. It may change based on v17.11 code base. > > > > > > > > > > > > typedef: > > > > phys_addr_t > > > > > > > > structures: > > > > > > > > struct rte_memseg::phys_addr > > > > struct rte_mbuf::buf_physaddr > > > > > > > > functions: > > > > rte_mempool_populate_phys() > > > > rte_mempool_populate_phys_tab() > > > > rte_eal_using_phys_addrs() > > > > rte_mem_virt2phy() > > > > rte_dump_physmem_layout() > > > > rte_eal_get_physmem_layout() > > > > rte_eal_get_physmem_size() > > > > rte_malloc_virt2phy() > > > > rte_mem_phy2mch() > > > > > > > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> > > > > > > Acked-by: Santosh Shukla <santosh.shukla@caviumnetworks.com> > > > > > Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com> > > Acked-by: Olivier Matz <olivier.matz@6wind.com> Acked-by: Thomas Monjalon <thomas@monjalon.net> The name will probably be discussed. Applied, thanks
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 257dcba32..379920fbb 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -64,3 +64,10 @@ Deprecation Notices be removed in 17.11: - ``rte_eal_parse_devargs_str``, replaced by ``rte_eal_devargs_parse`` + +* eal: An ABI change is planned for 17.11 to make dpdk aware of IOVA address + translation scheme. + Reference to phys address in eal data-structure or functions may change to + IOVA address or more appropriate name. + The change will be only for the name. + Functional aspects of the API or data-structure will remain same.