From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0049.outbound.protection.outlook.com [104.47.34.49]) by dpdk.org (Postfix) with ESMTP id 4220A5592 for ; Mon, 10 Jul 2017 18:23:04 +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=SsjyX+dGPAqD2njku2pDIABTZsVyibSehYnDRxpiZbM=; b=HhRX0+lv9z1jrbJMO9Obo6/4hK7juuI/9HocttryrN+wd68ugMrEYa9BcKLM8Sr9yPI7ZD4jVV3Q4IO4308Wb9pF/jQkUjGYCyVUk6iNCmvVSRvnBJIttobymSuXMv9n3fOQfb03dbIfS6KidDbv2IDw2GGohqDLqWjSDacH8HY= Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=caviumnetworks.com; Received: from [192.168.0.103] (103.76.56.167) by CY4PR07MB3093.namprd07.prod.outlook.com (10.172.115.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Mon, 10 Jul 2017 16:23:00 +0000 To: Olivier Matz References: <20170621173248.1313-1-santosh.shukla@caviumnetworks.com> <20170621173248.1313-4-santosh.shukla@caviumnetworks.com> <20170703183720.381369de@platinum> <20170710151511.7972e83d@platinum> Cc: dev@dpdk.org, thomas@monjalon.net, hemant.agrawal@nxp.com, jerin.jacob@caviumnetworks.com, bruce.richardson@intel.com From: santosh Message-ID: <89741f40-8418-1734-0f62-589e59a4dee7@caviumnetworks.com> Date: Mon, 10 Jul 2017 21:52:45 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170710151511.7972e83d@platinum> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Originating-IP: [103.76.56.167] X-ClientProxiedBy: SG2PR0401CA0018.apcprd04.prod.outlook.com (10.170.128.156) To CY4PR07MB3093.namprd07.prod.outlook.com (10.172.115.7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2c0110be-1b5b-4d5c-2294-08d4c7afefed 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:CY4PR07MB3093; X-Microsoft-Exchange-Diagnostics: 1; CY4PR07MB3093; 3:mrrmdDD/26pJsbIFKTFL0//h8QKEAbmgkcUofR4gybtGtqEBnAu2GhdgW+joIlRONvCSLxjdph2Yw8gsHSABG0Rgp1DKEbXWoFTQbKEikUhjzzQchQf9/eDEoAmUUF2FaQbJQtc6Br9mmO5Vaga2NgAY7nLiyWbNnXOToGMzEH8sKmAgo+ZmfijTfRrf7PEdWqj9HpL8IquLG9I7qp1hY+G1I919OJBKretBPBXbHktP//XKpV/j9u2sIKmeGzSHRcFjgflY5/2p+4hZGsw+6qCUh6sMi/c3Spt2MxvGQCDjYNHZWlhg67b6l4uCY3vWhJ4jvFBA80+L7pCbbZ5CFlBe6lC7R8l7aJ/C3NfCOOO8CS/AcofXX6ABjDH8sDh+oWRDuRRkiXzBelc7HIvMnk+IxjVSLX9hH1JfOM1/8FPPamEzcGNulEIBcZFRMDn83hvQmU9w+Zbhk3p8lEKaUZEHYSRzzkfMSa8vMY4ifEiXlKhz+VjBhcXJdmQWdWtJOg1vwh3IT+GNwae5Y9vemb0zB8cj0C69XtDYjCbaBxzcx7NQjLZ3KEs6YARnuFLjjAb88ONFEnph597rEdHBN8fxVvx2JWCWTbmJ4rvI4jXXlL261Nqg9Y/RD1LiwP6A8BkZTYbdd8EYL5wmM/3W2mhZYMSIA2c8+4YqIwdGxcyGr+GwpXmdlc7pg8trj1o3cfdbHL/Ck81mR2S2+3HyrtWOUVB0z2rr0mNIFTTdQuU= X-MS-TrafficTypeDiagnostic: CY4PR07MB3093: X-Microsoft-Exchange-Diagnostics: 1; CY4PR07MB3093; 25:R2skxP77cJvTIbx5F63r9hUTHJU0VbA0DtzR2O21Y0gx32h62mpxgG9H9UAuUSTRU9STEoVxNcxzkXcu9qLeWYH8CD2yqNon17rF/A3ywQj0z5CQ7+K6Wcx3ErEnwMzqpZHu8pEv5HUSiD3fVeIAnnTQZ1w9bV7vJubcOfzol9VZJD3iGTsQWLOAftHb+rTQkC+TNma/7qfW43wkZVnVB/SMusNMRVoGzROUe/rqggvRy+D4OKbXgxxEgIcOF4/3UIwf79wRmusxvJ22FsWD+xu14KC8mawvmQkdAgOVq9PlxRY82RwcflXIDaS5m1hu3YX0fktGLYS/Nyl9yeVDqvZbZ4uewexi+xlhHSR3VYII0du3m2QjYS0J3smzIEOyR8fJNSO+k1UxUoZ/N/P15Yitie2rdyCaSKo1wgOzWp20dz2qHA/xMrXIpMkB/GT/ui3jrVlRvvsH1BjeZDeKksaRB+2CmLlXpq8wa1Jjamz7oNakBur/jWRlCqeJX4tKCWIjHVZ3k9vElG5Du+AovdgFoRS1iuFAkdNY+KWSQfNQDYiGyc2WswKcy9F+vyPrzSuEkyuu0PWifev+n3W78B6PcYGFiLFXwviFHPyakZXahPQaVjvzT2eKD0pCTe+PG28vGHx7ZZeUWAlLppOle3y9RIUTXNLWFeC46/LLyg5s6gowzne6M1an5gbO7iDy0IZ5nSiaQp+VKJX6IqeCm9YR+BOKvFZyi8kogLCi8Gf6ad5wJdi+wUOoNSZYE1n14+p1Or0k3cGp+84nvoXOswD2vqwV0dQRg/dwjDm/sMGOkSzKetooRHPjTToJdEWlPTuthfEYTYJ1XJ1/Rv5MnZgqFziDQfh4tsMN1FxsVDDMmVU+cB775dg39DZ1xc6nW37v+EAK6AgkyA8geZZR96RwGbf30XBmRfGdEHnf0p0= X-Microsoft-Exchange-Diagnostics: 1; CY4PR07MB3093; 31:ONiZ+ZAJpHVTFUFiEQt4A+ODc0Rn2LxwGtQjEg+kEDA5V6a0F/1GtY98BdqX7GijpFKQzfC0mhCVT/LAK2PruBglpgpM3hDKhZUiq13lYRAHq7nGAMD9HDRGeaYegmxPjjq8AlciL6W8RbuEu+XTD2ZDc1Mq5D8HofG4kpFw8Jcz/0W2rLvw3Pe5o1LWvHD/GuSr+rX/ZmeVwfcKY9CTtFR8bjzVqNNWQeZKFpLGyW2xzBRFqF4jmjttTPvmD/0dQQdPYL86VFoVJ0it79sAQrT3kVReMaokGfIEkbR8kaXspq8aVHwjl32/zWw33VR3dc8W1A7nr9nbtgv5IWxYyFcBpb22YRVPvlAF69o8i2YhjObANgsqJlW7dtQ0pccRJfY/juw47ZueHb9Y6sYeq6lJJ8FBl1ifPNifYzKtEBGonX0RMDAXp9iwEy2f5lIczIo/DPPRIJ9EiKxkimeXxSUgbn1ZnRTmCwCihZF+/h0E52pZMlWbaaUQZbXBKRR7s3mTLd+ehYgcpd+A0ZtR9EE5PhhSUBTxmtBGfHPtFXo0TlO20mi87n6ghhUIiCefTIrk/MJ7enCZVwSyodiUhZcKYCZIGWnMuQqxb1vDRsnYS43dDGl48r7raONkhpkGqaXCznaLQXPraNYKeRO0h4wpaSC/ME6im4P5KIwN+EA= X-Microsoft-Exchange-Diagnostics: 1; CY4PR07MB3093; 20:JbD7Yuq48a/iAPhpdgMINahfK8CJxIsmwICPYzOPKQhveB16ER31iZ7TRpu68HL++1bAoqIN4ZZ+Mukk1f0cshVymfCwG0xZp2jrLdWvyJFgUMCes/tN1l0SJXPSed9cwLWChCe2MP+V8j6ckB1gLtHIThaHJ+Tvix78Yn+IrFPzYOfXjisyP51Jvw9HZzzFIg4RDHat9gF82hOwCGDaIW/yYl/leg3HHhrlHzHx8hnj7/Z6Esct55thAi+R8YnqFlHoXPrG9rH/z22n27ywlYHLB6Bo1YHsKMVTA1An38m6bWqKQB5yULn2G+Hrxxv1p2/oFuMaeSqenDfiAjvprVTE2/Gwuow1ZWiz4wWaMJK209g7UVn2g5nRQ9S1yjZDUndsjxDXPDN8DDC7qjQRd+4k4b0WBGF1r0q4I+Q1QgQ8rrXRWmqiDAjmh82POwPM89fg4U4CImLLghQEb6LIs8C+9s4vtkPfyx8FxWwXemWiTZmdRpD3TCnmMk8XGtwDmVlNM0gbAtxpUpWaD0BJahUFE8wJK1ErTRI+OdYYuqtb6iJ/GfVNQxuMP+l1yinOytVaJe8sUnNC7VXxHuQNmYI5/8Q3G/jJ2xMVUw82OyA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278178393323532)(236129657087228)(48057245064654)(148574349560750)(247924648384137); 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)(93006095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR07MB3093; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR07MB3093; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY4PR07MB3093; 4:Wr15dHtQaWOun+djQ/MPO9KgNPgTo2sBL8yz2y?= =?Windows-1252?Q?M3SiBv1bD+s+2xbO5MmBmdF776rMt3xINA7dGy2t8faMWwNAFlJrj2PQ?= =?Windows-1252?Q?jGpgpFesLZ5+xU2YxGrCf49Wkv9b33FG1hGkJ7WzBkKGXJXyUD4mJtlu?= =?Windows-1252?Q?swoxwr9DgV9jKlzTiWryXaD1i+eHscKcFQruOucTLOIEq8yLdWGkoPLw?= =?Windows-1252?Q?oRE/tssLdRgyyfYAVhiZcGEUWlTSQyRgt3tUlgc0pYdcnytVKq8nEEuc?= =?Windows-1252?Q?cG7fgqvPl6l0iZlQ2xtG+zoEcf8xUvNTFuw2T87VnbWy5MMcLf40Yc2S?= =?Windows-1252?Q?LiP5VYRL6dhi6QA9yY6OmmjBdOqCRVC4szlDUCUUcPxRyXguHU5jMbDN?= =?Windows-1252?Q?FlxIS/xtpRkiU9F0CE6PF2sb0/0KPaqqDVmk4M66SV2vJpfY6T+pGxCG?= =?Windows-1252?Q?o1+DUk6+e1q5dRYWKmqUqQxLM/LCsr5/E7UNVMceVT6pjR6C0DtF67d/?= =?Windows-1252?Q?sH942LiKoZKm+hhVZLhLzturPvJ5tfWc1swxsIDLAcsNA+pLpbFY/2+9?= =?Windows-1252?Q?ki4zyE6RUqyIF8VTDqacN49Bstd1+sOmELWEdTaaflxqOegBC21201cZ?= =?Windows-1252?Q?Dwh6QDrx/PHqp4WGP3ltp/33b1L6jwjWq3ueDYTtyjFFJhIAY40zulop?= =?Windows-1252?Q?ez4DsqdBhZOesvd0NxkJ3a8PlEiFgnOO8HMgBG+sG9h5B38m6TB0AgB8?= =?Windows-1252?Q?8X4Ext2anOCAcM7FO0Lnb0u5kILBRoXb83dp/NkXu/t33ljPj/KuHkRW?= =?Windows-1252?Q?GQTC7zfB95cWKsFpNjroL5sQ+JQBjKPiXN1ZftWWvOYPgS90YujdULSS?= =?Windows-1252?Q?sGuT5/bSQYDEQP72cMhd7FKPZqf0ovZBmMe2cOvZNBZ6tVVYllMvSSvx?= =?Windows-1252?Q?Htf5m2d+kRXLEVrNa5yVTkRYLuQl2eI/vWFCXzMTtRyutz+9Y4V2uLoF?= =?Windows-1252?Q?CbrSyit6JBvf33DaprH3gIbr/ghHdL7mk7g8yTJV1iu9EJdoR4vIFxb0?= =?Windows-1252?Q?ACXAat3uCZsNNhYp9bKaNfuCDJa0mlHdHpozTGThTZSXrekvQxitiS32?= =?Windows-1252?Q?WBsKDsqsj3Q/0ovrXB9IKoSd9iSbWwSIQTsXK47URNAmnsQ3dtWvMU2w?= =?Windows-1252?Q?mnag/5+umuSFAcnF4qRsrizlhS9v9kItjSuIZh/9sI+xEyvYOTBP99J+?= =?Windows-1252?Q?qrQKf7qTBZCWuq3krcHeR/xnHy8vFcFqwSynboL+5YTYYLICwhbFwfM/?= =?Windows-1252?Q?iaWAcKB1nqHv9iZ3Z1zPyXZ49DooDu32pCwhxe5BzSHgfml8WoQsFh2y?= =?Windows-1252?Q?7Q6POgO/KLaG6D6sy4Ya+fK3AotjpPgNuR77P3eunVpVhSGKAPexmTD2?= =?Windows-1252?Q?KMGrXm+K2bcEF8b6cO?= X-Forefront-PRVS: 03648EFF89 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(7370300001)(4630300001)(6049001)(6009001)(39400400002)(39850400002)(39410400002)(39840400002)(39450400003)(377454003)(24454002)(3846002)(6916009)(42882006)(2950100002)(53376002)(478600001)(4326008)(93886004)(229853002)(6116002)(6246003)(110136004)(38730400002)(72206003)(6306002)(6486002)(230700001)(50466002)(53936002)(6666003)(31686004)(77096006)(8656002)(90366009)(42186005)(966005)(86152003)(76176999)(189998001)(50986999)(4001350100001)(5660300001)(305945005)(54356999)(83506001)(7736002)(66066001)(31696002)(117156002)(65806001)(47776003)(7350300001)(33646002)(81166006)(23746002)(65956001)(25786009)(2906002)(36756003)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR07MB3093; H:[192.168.0.103]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY4PR07MB3093; 23:KYc63Rm70U/W1cwfFBmJHSubIwmbqpV9HsTwg?= =?Windows-1252?Q?zRq8/3cKzE8menVGLc/zANrYQhHTS843zqwkABM4Ja/EcPyvUX6no2M1?= =?Windows-1252?Q?6rP0aY5fiyrsC7A8ixxY0UkVTHm80gEnBxpYaYMUzuov8G3I7tRzPtBo?= =?Windows-1252?Q?XpedpSCm1vhuNhaL7usgl0wbMF9G/EepENlX0MMfcoQA5pli8gJ+nt8l?= =?Windows-1252?Q?erXOBFQu+U1GnWQLdXi18w7Mbr+JUXaMQWsDjthiiQWRi/TMlp3DHuSd?= =?Windows-1252?Q?Cy5E/Z+oVNvDhzGsjK64B9Y/MToS04GrOt0tydH1AJ0c/yZtGkw8npi6?= =?Windows-1252?Q?h34jwSQeoUcyafZgpdVAmzJDR10/fhnu8iIJbQu7J6vmoHeL5irmjxxs?= =?Windows-1252?Q?2xbrnR793VtDrEddTFobc6ywFM9ClzdEENMR7yzo9PMd+tDM7nyp59/z?= =?Windows-1252?Q?vq6sDPxYniIem4PtAkUJdXqmQRA8JJGUjMvIQOYK+ItDvOjNNJHeIle7?= =?Windows-1252?Q?KCeZkfAt0zf/1PqDgUv3ASoz3UQbMnWmmDP7DP9lfUwSgj70l4MZRJkM?= =?Windows-1252?Q?VmVWMRjEiAZrK57PMllLwW54j11h7AZeeCgjZ4Hu/1P7pnPRbCI9gZy0?= =?Windows-1252?Q?59QRm9RkTzae4UAEDlKZAO3sO73n4baQdLUdQ478T3UiULKQ0FVu1Ykw?= =?Windows-1252?Q?J5ZnQCi1IuZPDjoOT0J1F2uaJHBmmhdk01kZf4lDEb8wdYIImh4Sby6F?= =?Windows-1252?Q?fCicEf00NRrYrJKPt6yK4UUmA2AgbKyRjstDNivi4iCIdDTGfVQmfU55?= =?Windows-1252?Q?BWF1zi/02CrnbWnJr8wyp3DGOMdSbVmB5RD0RAYGnVU9oGZqQlaxTyhh?= =?Windows-1252?Q?D73jjMtfDfZj/Bqq4YF1Z+buusZ3zUlg5OSogvWeTNAoKhvLGvMIrW9e?= =?Windows-1252?Q?+VNr4JOBPTR+DF4LMb7KoB5E9r5ugQ8MRZ1/NOTi++mirbpRAQfvjxZ+?= =?Windows-1252?Q?qP6uK5iquxQV/QkSgDzv1CmwKAxpAQViQzIeC6najjRxJCayVWVTg/Gl?= =?Windows-1252?Q?8S5zhGZcQ2W0bqWXGFTQdRPMrSW/5w6JuCWgEGn1F6R1D7zgshu9Rufc?= =?Windows-1252?Q?v4V7+f1KDanVE6Ydb6ZVQdDurIZ3Mksjxps2eF7L98TN3nOXOMSl5ELY?= =?Windows-1252?Q?BXnrZoyBkDocxVOGr3WSnS/yCsQhkq0Fi9Yw8KehXBQVBWa0/vrzJmVx?= =?Windows-1252?Q?aU1WYG8iQ514JDnOiOUxX+XHkFZNYl6vjSuCIpBtALKgB+3Xn3VBDH8s?= =?Windows-1252?Q?QeXQ7QE3o4klHNmyEfmSFErwsxAiFl9o8UpTdrxxF1wcXXlpx6zX/nn3?= =?Windows-1252?Q?ndwCipN1V1BOHsfHXQLdIkfuDXzjsa1YNTaq36zKV1+y41xd5nln25pl?= =?Windows-1252?Q?jERv42csDOSzIXbyWCvPcjhESsZqqYN5i/XIHNtbrVo9nJ/NSXoLGFbH?= =?Windows-1252?Q?4/PuB85hxewkPSFpzrj2s8hTPbASAwngzjT2vvxgLviWXlYImlCkSgQy?= =?Windows-1252?Q?7v+/stPvvd+18eM/pk5ntAER41kQ6KbGKLnQd3jwYf6R59/HGu86r+qj?= =?Windows-1252?B?Zz09?= X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY4PR07MB3093; 6:jS7/YxqoePGhMkQNMK5iIyVZpXE1ALX/ZtNg5U?= =?Windows-1252?Q?V3QH5cubX0iXkvwDkQBKZ9Asf2GDZb1Tq12voVuV+C0/XvTyVlRwEcvA?= =?Windows-1252?Q?cpK7oukP7C1PqFyLt/wf87xFP4OC0KobeheAvAit1Uy/im9hmUPKseiA?= =?Windows-1252?Q?9jxbyhIW04SVUTj7jeZo7BCJdU26ovBfqU1sZcu0RhR9rvqKsPVkVXdi?= =?Windows-1252?Q?aZ9dV/+pWKm0XhRIScVxyqZsDGIKzy5t362h6yi2QxEVvI8droAKgp9n?= =?Windows-1252?Q?vBXMqH6lFw7CKFgV1iv7nGgfstUtn5i3DLLx8o6buNhjrP5GbphO+mrz?= =?Windows-1252?Q?TqJ+RlUUZejJQEV+vUixZBK07vCt2t82o8yeBoY3el4xerYQUkqqeGzt?= =?Windows-1252?Q?pVEwqq9JqNnl8sI3zt2BCGG8EHQc2o8tgz77BJtgTpG+EvQ2dQw7ChWt?= =?Windows-1252?Q?fu50UzQP1ZrUZ6pjOu5U3S0YzKjC/yR6EVQgKu3Wl4iHlNnFDbT806+Z?= =?Windows-1252?Q?PUGuX31sx/+6nu+v6uEP2HImfIMjdjsHIFfa4IWD9sLU6XaSzjFerbVI?= =?Windows-1252?Q?HM5QxF5lKOwyaIp5r+kytuqqGjikp4dYM5cCdP/EaROzSQFRXffDT3X2?= =?Windows-1252?Q?Xo/bs9QZ3+kXi5RGS1H2o4S7gGSLX53zq5n6Mz9yd0X59zk8zZUSOith?= =?Windows-1252?Q?0j+p39KNBHyEX4K1W9VCBI1W96Ap03E8kPsD3M3uNttK6P6GahYVgBC6?= =?Windows-1252?Q?EaQjo4rpM1fj83okcvATjqykPzRk6NsxhZ9HC1oh3zC0BEjj/Wip5LiQ?= =?Windows-1252?Q?Zx9lUocSK3T0hF7xgwKr+B/zIJgwoqOXwwODg5F8v/yTal9hlE3UcHUd?= =?Windows-1252?Q?ju4In3qUouwmYcx05DFvyMQYyysQxBKtfjCDu+4KPhq0CNeowBl3fw2f?= =?Windows-1252?Q?TOmsBhDsR5g/OF6EbkFfaC2gu1AXeSOo6QK8pN4NU0/LBA9fmwau8tDS?= =?Windows-1252?Q?edcPmNJIpPVdVL4Q9WR8Aa4zuxjaQhASvlRdT8Bu4zfY5tMRjQkzUACX?= =?Windows-1252?Q?cP7KYC2nR7Q8g=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR07MB3093; 5:XffHChU+5KXF+9x97kLIuNG89fg/rOFjuzX1W7HqVTQivIp4p+3ydqNyjqrPk68Q6GHwdo6k/9+oE72HHzgGF2wed1V/OGvftzVQQF/L1mQ/E16y3DorIW9poyrTxVCLlenieq0xWUqPJaZJMkelVMBD36io45GwMeZPDYAUq9WGwkWN51kq1s7IjG+Af32Grs4EsiaEM00vzsoLpbZNuhpO8cuRlplI9uxsqfLiHV65KjH7ZkdZknNm2yFHSSuztvufDZ4mVsqeCTmd/gnn+oGfm83VISRdw7dlfuhpVKR8hbEWOZYb5dorB+txR3GlHQ60+YvE7WwfiUJxRVP38uMkySEkWrFdrm1cJne0W380I2z60+ypcREG5ERA/B9tjpSK94/KSYgIRDXfA1vrqIhXlAjsQrNWv/yPW35azjGQcyx65XNjzjOdunvmLD5vVcWCjiKcj191azE/Fdwy8SO5Y3+g4IJOeCOEfmyPr4fF6yUIw274t8Sog0AAhKmL; 24:jpLzMwNEvbpbADH/8KvXry3CJv7swaWZ4gVw8JgQde5jFVcgqtHBKgHHBOVFCBydAY+9vKhtJkzi34bcRj31oI3zYuR7JcUHO6iIep0Gtkc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY4PR07MB3093; 7:LK7hfqv3VNMV8068dUNrjKlYG4d0xWeXHFb0fpGIl4Q7ONDri1K9sungMryZu8BWN27pfDQDYCnOknV4DEks9rVfOmJG96QmzdE2Losj8yelzz98wqD7cRmoxMCdSsksmVaImmm/yzN5YOphBQ688gpuiwIvt0F2L5dQq+ta8efjkDDpA+U/SlG/EEL9fkZ+ZZulMqXk8XuJz9VBU5qjWQ9nWn4Nw54qUVED5x1rUwnydJN5kwyqVn7Ndim2WZk/wmj50y8qeeJdAqG40KWjVGKv8DYwuPdwqcV09y/0FJQqFEGKtedkPkAswAV3h+1uCMSq9a1m+cO34at+Skv6rXGCnq6WBB7kVUkGL1YdOEe0va8Zyex+Hc57cQA+zvjNRwr7CgDoOIuxbpB+N4zKN9m8l3NwcY5CHGRphP7YNO60ZuhiNh4Ij7y9W/yTRm4KJgaDe4iPGmWlIzpw8Qd4G7MJJu8qO3rHGn2NokMhHL/2QRwDMPyhXrdr0ksv49ks7eyRjkHtPYvBAQnU6ZvXRocMGKfcW1jgODULGdcjvuJPb43QmBwLOcRJdysUDnv1XhwPHn6gzi3J/RGKKBCBgRK2o2lk9IiFqbkSJAp4G6r5Eq0Ujue62oTNxk4XtL/71ZR8BBYwoiVCXpb7cEdOIpFbARguVw0m0ZRUKmyfUxrDNCO/FWU43z73mn+uXUIoCozYYePfRxHugz5aMH4aomXWEamoAPY1ETx0RAfcopBfe1f199Ba4Y1XpPJ8bol1fHHNigpgjwuTrv6RW7rYWMrCmkTio8OOZUnEvCASgs8= X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jul 2017 16:23:00.2082 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR07MB3093 Subject: Re: [dpdk-dev] [PATCH 3/4] mempool: introduce block size align flag 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: Mon, 10 Jul 2017 16:23:05 -0000 On Monday 10 July 2017 06:45 PM, Olivier Matz wrote: > On Wed, 5 Jul 2017 13:05:57 +0530, santosh wrote: >> Hi Olivier, >> >> On Monday 03 July 2017 10:07 PM, Olivier Matz wrote: >> >>> On Wed, 21 Jun 2017 17:32:47 +0000, Santosh Shukla wrote: >>>> Some mempool hw like octeontx/fpa block, demands block size aligned >>>> buffer address. >>>> >>> What is the meaning of block size aligned? >> block size is total_elem_sz. >> >>> Does it mean that the address has to be a multiple of total_elt_size? >> yes. >> >>> Is this constraint on the virtual address only? >>> >> both. > You mean virtual address and physical address must be a multiple of > total_elt_size? How is it possible? > > For instance, I have this on my dpdk instance: > Segment 0: phys:0x52c00000, len:4194304, virt:0x7fed26000000, socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0 > Segment 1: phys:0x53400000, len:163577856, virt:0x7fed1c200000, socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0 > Segment 2: phys:0x5d400000, len:20971520, virt:0x7fed1ac00000, socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0 > ... > > I assume total_elt_size is 2176. > > In segment 0, I need to use (virt = 0x7fed26000000 + 1536) to be > multiple of 2176. But the corresponding physical address (0x52c00000 + 1536) > is not multiple of 2176. > > > Please clarify if only the virtual address has to be aligned. Yes. Its a virtual address. > >>>> Introducing an MEMPOOL_F_POOL_BLK_SZ_ALIGNED flag. >>>> If this flag is set: >>>> 1) adjust 'off' value to block size aligned value. >>>> 2) Allocate one additional buffer. This buffer is used to make sure that >>>> requested 'n' buffers get correctly populated to mempool. >>>> Example: >>>> elem_sz = 2432 // total element size. >>>> n = 2111 // requested number of buffer. >>>> off = 2304 // new buf_offset value after step 1) >>>> vaddr = 0x0 // actual start address of pool >>>> pool_len = 5133952 // total pool length i.e.. (elem_sz * n) >>>> >>>> Since 'off' is a non-zero value so below condition would fail for the >>>> block size align case. >>>> >>>> (((vaddr + off) + (elem_sz * n)) <= (vaddr + pool_len)) >>>> >>>> Which is incorrect behavior. Additional buffer will solve this >>>> problem and correctly populate 'n' buffer to mempool for the aligned >>>> mode. >>> Sorry, but the example is not very clear. >>> >> which part? >> >> I'll try to reword. >> >> The problem statement is: >> - We want start of buffer address aligned to block_sz aka total_elt_sz. >> >> Proposed solution in this patch: >> - Let's say that we get 'x' size of memory chunk from memzone. >> - Ideally we start using buffer at address 0 to...(x-block_sz). >> - Not necessarily first buffer address i.e. 0 is aligned to block_sz. >> - So we derive offset value for block_sz alignment purpose i.e..'off' . >> - That 'off' makes sure that first va/pa address of buffer is blk_sz aligned. >> - Calculating 'off' may end up sacrificing first buffer of pool. So total >> number of buffer in pool is n-1, Which is incorrect behavior, Thats why >> we add 1 addition buffer. We request memzone to allocate (n+1 * total_elt_sz) pool >> area when F_BLK_SZ_ALIGNED flag is set. >> >>>> Signed-off-by: Santosh Shukla >>>> Signed-off-by: Jerin Jacob >>>> --- >>>> lib/librte_mempool/rte_mempool.c | 19 ++++++++++++++++--- >>>> lib/librte_mempool/rte_mempool.h | 1 + >>>> 2 files changed, 17 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c >>>> index 7dec2f51d..2010857f0 100644 >>>> --- a/lib/librte_mempool/rte_mempool.c >>>> +++ b/lib/librte_mempool/rte_mempool.c >>>> @@ -350,7 +350,7 @@ rte_mempool_populate_phys(struct rte_mempool *mp, char *vaddr, >>>> { >>>> unsigned total_elt_sz; >>>> unsigned i = 0; >>>> - size_t off; >>>> + size_t off, delta; >>>> struct rte_mempool_memhdr *memhdr; >>>> int ret; >>>> >>>> @@ -387,7 +387,15 @@ rte_mempool_populate_phys(struct rte_mempool *mp, char *vaddr, >>>> memhdr->free_cb = free_cb; >>>> memhdr->opaque = opaque; >>>> >>>> - if (mp->flags & MEMPOOL_F_NO_CACHE_ALIGN) >>>> + if (mp->flags & MEMPOOL_F_POOL_BLK_SZ_ALIGNED) { >>>> + delta = (uintptr_t)vaddr % total_elt_sz; >>>> + off = total_elt_sz - delta; >>>> + /* Validate alignment */ >>>> + if (((uintptr_t)vaddr + off) % total_elt_sz) { >>>> + RTE_LOG(ERR, MEMPOOL, "vaddr(%p) not aligned to total_elt_sz(%u)\n", (vaddr + off), total_elt_sz); >>>> + return -EINVAL; >>>> + } >>>> + } else if (mp->flags & MEMPOOL_F_NO_CACHE_ALIGN) >>>> off = RTE_PTR_ALIGN_CEIL(vaddr, 8) - vaddr; >>>> else >>>> off = RTE_PTR_ALIGN_CEIL(vaddr, RTE_CACHE_LINE_SIZE) - vaddr; >>> What is the purpose of this test? Can it fail? >> Purpose is to sanity check blk_sz alignment. No it won;t fail. >> I thought better to keep sanity check but if you see no value >> then will remove in v2? > yes please > > >>> Not sure having the delta variable is helpful. However, adding a >>> small comment like this could help: >>> >>> /* align object start address to a multiple of total_elt_sz */ >>> off = total_elt_sz - ((uintptr_t)vaddr % total_elt_sz); >>> >>> About style, please don't mix brackets and no-bracket blocks in the >>> same if/elseif/else. >> ok, in v2. >> >>>> @@ -555,8 +563,13 @@ rte_mempool_populate_default(struct rte_mempool *mp) >>>> } >>>> >>>> total_elt_sz = mp->header_size + mp->elt_size + mp->trailer_size; >>>> + >>>> for (mz_id = 0, n = mp->size; n > 0; mz_id++, n -= ret) { >>>> - size = rte_mempool_xmem_size(n, total_elt_sz, pg_shift); >>>> + if (mp->flags & MEMPOOL_F_POOL_BLK_SZ_ALIGNED) >>>> + size = rte_mempool_xmem_size(n + 1, total_elt_sz, >>>> + pg_shift); >>>> + else >>>> + size = rte_mempool_xmem_size(n, total_elt_sz, pg_shift); >>>> >>>> ret = snprintf(mz_name, sizeof(mz_name), >>>> RTE_MEMPOOL_MZ_FORMAT "_%d", mp->name, mz_id); >>> One issue I see here is that this new flag breaks the function >>> rte_mempool_xmem_size(), which calculates the maximum amount of memory >>> required to store a given number of objects. >>> >>> It also probably breaks rte_mempool_xmem_usage(). >>> >>> I don't have any good solution for now. A possibility is to change >>> the behavior of these functions for everyone, meaning that we will >>> always reserve more memory that really required. If this is done on >>> every memory chunk (struct rte_mempool_memhdr), it can eat a lot >>> of memory. >>> >>> Another approach would be to change the API of this function to >>> pass the capability flags, or the mempool pointer... but there is >>> a problem because these functions are usually called before the >>> mempool is instanciated. >>> >> Per my description on [1/4]. If we agree to call >> _ops_get_capability() at very beginning i.e.. at _populate_default() >> then 'mp->flag' has capability flag. and We could add one more argument >> in _xmem_size( , flag)/_xmem_usage(, flag). >> - xmem_size / xmem_usage() to check for that capability bit in 'flag'. >> - if set then increase 'elt_num' by num. >> >> That way your approach 2) make sense to me and it will very well fit >> in design. Won't waste memory like you mentioned in approach 1). >> >> Does that make sense? > The use case of rte_mempool_xmem_size()/rte_mempool_xmem_usage() > is to determine how much memory is needed to instanciate a mempool: > > sz = rte_mempool_xmem_size(...); > ptr = allocate(sz); > paddr_table = get_phys_map(ptr); > mp = rte_mempool_xmem_create(..., ptr, ..., paddr_table, ...); > > If we want to transform the code to use another mempool_ops, it is > not possible: > > mp = rte_mempool_create_empty(); > rte_mempool_set_ops_byname(mp, "my-handler"); > sz = rte_mempool_xmem_size(...); /* <<< the mp pointer is not passed */ > ptr = allocate(sz); > paddr_table = get_phys_map(ptr); > mp = rte_mempool_xmem_create(..., ptr, ..., paddr_table, ...); > > So, yes, this approach would work but it needs to change the API. > I think it is possible to keep a compat with previous versions. > > Ok. I'm planning to send out deprecation notice for xmem_size/usage api. Does that make sense to you? >>>> diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h >>>> index fd8722e69..99a20263d 100644 >>>> --- a/lib/librte_mempool/rte_mempool.h >>>> +++ b/lib/librte_mempool/rte_mempool.h >>>> @@ -267,6 +267,7 @@ struct rte_mempool { >>>> #define MEMPOOL_F_POOL_CREATED 0x0010 /**< Internal: pool is created. */ >>>> #define MEMPOOL_F_NO_PHYS_CONTIG 0x0020 /**< Don't need physically contiguous objs. */ >>>> #define MEMPOOL_F_POOL_CONTIG 0x0040 /**< Detect physcially contiguous objs */ >>>> +#define MEMPOOL_F_POOL_BLK_SZ_ALIGNED 0x0080 /**< Align buffer address to block size*/ >>>> >>>> /** >>>> * @internal When debug is enabled, store some statistics. >>> Same comment than for patch 3: the explanation should really be clarified. >>> It's a hw specific limitation, which won't be obvious for the people that >>> will read that code, so we must document it as clear as possible. >>> >> I won't see this as HW limitation. As mentioned in [1/4], even application >> can request for block alignment, right? > What would be the reason for an application would request this block aligment? > The total size of the element is usually not known by the application, > because the mempool adds its header and footer. > There were patches for custom alignment in past [1]. So its not new initiative. Application don't have to know the internal block_size (total_elem_sz), but My point is - Application can very much request for start address aligned to block_size. Besides that, We have enough space in MEMPOOL_F_ area so keeping alignment_flag is not a problem. Thanks. [1] http://dpdk.org/dev/patchwork/patch/23885/ [1] http://dpdk.org/dev/patchwork/patch/23885/