From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0089.outbound.protection.outlook.com [104.47.37.89]) by dpdk.org (Postfix) with ESMTP id 1A3972B89 for ; Sat, 29 Jul 2017 17:13:15 +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=Ne8P1Du4JOwe5iiAEJy2rHRYv9sR8YuqXJ6g4DzrF5Q=; b=F9CZNJgMPu4YzKZTVRHVytsXC3wOVs9vPAVAC535vyHyA1O/rKWX1jeetsj8ozZDXsm9xBaEKT2kjTt7ANw3/wWU/U7VHK8vokvmdQzsiAGjtN6VbR6L58ijY4V9kkl7f1Lx8h8tHyrqQg1kRIwJKV/VJCPKj8Gr7cvPPpw2C4Q= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (122.167.85.29) by CY1PR07MB2442.namprd07.prod.outlook.com (10.166.195.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Sat, 29 Jul 2017 15:13:09 +0000 Date: Sat, 29 Jul 2017 20:42:54 +0530 From: Jerin Jacob To: "Rao, Nikhil" Cc: gage.eads@intel.com, dev@dpdk.org, thomas@monjalon.net, bruce.richardson@intel.com, harry.van.haaren@intel.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com, narender.vangati@intel.com, Abhinandan Gujjar Message-ID: <20170729151252.GA25166@jerin> References: <1499377952-5306-1-git-send-email-nikhil.rao@intel.com> <20170706141829.GA5260@jerin> <02aef899-da84-9281-e4a4-2871237ea20e@intel.com> <20170707150317.GA2007@jerin> <20170707155707.GA6245@jerin> <3d2d78cc-9572-bf95-6d25-9b350da62827@intel.com> <20170710104126.GA13609@jerin> <4197b5f1-9a15-5892-12d2-6bd142bc4d85@intel.com> <20170713184445.GA3659@jerin> <123ed8d6-4fd9-8bee-d86e-d270a092169e@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <123ed8d6-4fd9-8bee-d86e-d270a092169e@intel.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Originating-IP: [122.167.85.29] X-ClientProxiedBy: MA1PR01CA0113.INDPRD01.PROD.OUTLOOK.COM (10.174.56.157) To CY1PR07MB2442.namprd07.prod.outlook.com (10.166.195.19) X-MS-Office365-Filtering-Correlation-Id: 4e5a439e-17f0-44b3-f897-08d4d69454e4 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254143)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR07MB2442; X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2442; 3:9TckdfU3DTB6pOk8GE773ScpVFO9Ro8JfeN0YILYWCRELiePOx1meqKyTEQJVw5KYzVuDoJLZPqIWjhUROOQmiUkIl2+arxxoFc0H+JpCxZPnOcurcYcwj90nZin4L8Y34kMJ6K//Cymfx4jytGmGHM71mwXzLBkaoAFmGhvEJUK2bGxSXqKAgtLPsIT4Gc/irz3ptHLaaO75ac2/RtupsvCoScHVhfrY3kGJFStumtuEObjQFpKIdpgn1u88T9GhdHUTFfil+9k4ZCT+yWUrdm+8WLCk1uxP3zL1/WVG7BYvqhDyrCfe/L9+vIlfG76uUhvlv1rWWSg1U0BU4RWtD/IJGPEyssuYAucCj8KW/ZsWdgJHev0X3yr5i/sNRLXqCC2dwdnMhnZKXiQpkG65/YfuuZqb+ifUC0kS2oYN5WkFBscKhAiomxWmyDMLwDZoZShKjZyOssSkl6gMuYZGQYmkB2L3ZQ7Gmfck6c9xLV+QOJjRYUAn85BrooqVlwLQj+YHYjyaadmj6ppiUXdzSKMLPCVgJ2izRPKWoNSU8mcmO739nZfTpFhzF5nuHtNIQveCp+RAGzpbOjtW1eLsTNcSACInpJG/uESnrJqs6Uys0UREb+tc3coFZPJLkzJSqtCtonuBRqsu1R1nA9ytbDxmIKfDG3fahM84urjng7e9CuTm+wxCfXPHEN4kXL4q1p8F0mLfW1G2SUEf2Gku5QpE6n5W6NaCm5nZdhOY+8vHrqBmgYOAWh7Mfa/5J38SfEkkJl+eplpuvMall6Rf5+1ZULbDmnFxH43n7/CjpjNlm6Ku9+yt10MpeLW4hj/ X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY1PR07MB2442: X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2442; 25:ooG5APJEx5ie3vYZ/UsO8nIq3Sx5gWprBZJSC+9iWEjOyQ3vzqcLeg3CRwdUlu3b+ibHuAkzNBw6u7Bp/v5svAwV8wSf8lDFg2GUV5OAFjsB2xSrmHYm/xsOMsIcikExR7tiXpWIHqvuuyo7yhtnKBd14rDk0w8yLE0RnCfXzAipJw8YuXzMgJick6TvefCgBx6uXzg6t6UxZMMDkC8fifLMWyfUEFpl67Ofug9BrvMoMLuoQnH2wq54rynC4k1v5FiLC88mE6yqXLcNNt0HMnqbgQTJtqT9c8MmZdk+PJODzQ9eofZI8AMZ17J5YF3vW4VQNKEGWNhjUaHCxgVsru2apzYOfHVSeGEU0qXPtYCA/hKSUfLbk50dCnV3khWJ5xtXa2QVcID4L3wQ+V8zMeqVjh7gp9o66Ht7raflTuguNDkXj6YZdgfexTlssjrUsaCRHQCMt0t8JShuoTwcJcBVmtsaIMMvCpdPjPvT93dz19MxK1oserEof0EENvYlzZ7/VLG2ahb8gHJ5D1gxF9Tj2dMpV1OUuJMa9ZxU2MUseVzcNsXpVcGPLqDn6+i0dtm2VPIooUynVDSjkyaFZJZAQF0AskGaW/ZKiv05i+r6fPqn5a4vI3wUtzxSSOz1zaaSsRsbpN70RQLdVWIxql5kT1mKay7m56LKyQsdwi6gEVDMJxXobYSSmn0++ou3b1evb5cxlQtdTDg7T3yvGxUKK8l5/OpQiBBJm8bdCB6J9SS18qqonomAQQKf34LcYYJQhDUMjfnCnbseKMAwBY20xozpJDFXGKjn8ELn4FJtn1UADrkyRKYTKOiWv5OC2j+R/oQ1DxJp8jiqjYG7GbKU/vZ1u3ZLGX583EDfUsL63tnmi3BZ35+3aslOgYcVe0h6YCnMdg1BkkEEUVp11Khf8bN2PdC+1ArK8JyLXck= X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2442; 31:/6QGFAcDZ0hqviPleG0Krn+aj9s4NiRr2wPp/5dA4v+R0y8fpYsgnkq7aGo3W10hU+OFolqxepsFYSO8O6eXKZd8AlrdT8CzCPfOwPOCKwvU0CegvNoVLCxYvhlbPyTzA2sJXWkEy8oY968ll38oB4fy+jNWifzrhtjX14G+Cy9A/6IQJfb8u1rjbP1BixXKQmpz4BpRqs05/lkXiLDZySCj/xNp5wh9agwCWWuPk9VZIEdvcnqb71lZRnz/7JwlY9dLrXAUkLUjlFe2vtweeY2F301yu5FZ4FawQbYHIkuQ7AwuDUYVmSmJ9x91sYBWs/SED651kocsdB2loxnaE3Hcx8qS3/wQSYzG77EjTlx41JXlZFZfxaWoJLfSEZwT/xQ+BHspjIhVHXpspxv1pXUPOH5agdZ5JWGVT8samXfmr+4dvXLm44ymR/ggJUxjVkHZpx2J5eaGDbGne4JdLwLptyNGZTs7UuJXqCOkvr8nCRzNh2sYY7SFFsfaeXaFhU2WzmK1bn9jPunlA/YqL5W0rUM9pT+S2HCtBiC+QHUt6zB1aIAk0O9A7coilJDM86Gpe9T9wx06vx4dDNdOLwl3ThzYoHKqWzgN+rIy1Q8KRB3U5bYcruiA8KPas18nSf7eh1hqJPUmx7EE/rh9otzlmecPEpnNtKwntT4/5sDfU59Y0Cj/GWSlisqrTfUxDcqtkIPR2ph4qxqgUTJNwWCLaU3ad6VFjVfPP3tt0Yw= X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2442; 20:ECbr7A9do56NVOmpPVBhri3vGr7+SzOymHmEAJUq7G0jt3QhpXhZiVqKAAo0U8/EDdquQjIrcTdfo8zx7DiKM7iKQcQRaUmCFeYWQiWnmUCHD0k3kzjbcSCP77NbIc7GK+s6WbvuyTSTclxHqCZ/LI0OrfzftTMEsvmbFR1owkWxteyhlzT81FqySecB7OSFD4k61+oZm6jO4ZvbIvRwdMJhhvTlqdO1Vnb9Vi6gwvapauKkMbIUN3iT8zibypgaJomAUEmYECpmXZPgk8jn3HVMcfrwGce+jEBUOm0QG32r4y+s8YyP0HOfbROsBhDlasANHbpmYvPrfzjqvfv01zi94JTyB5WMEUyf7J5Gj48oKe8BEbpxFEidg7SNYdIPiVhnPShqUGdPXibDZjrOlD4jiA1rlX9Dpn1D3gfuv/332vf+GtAmUVc5cG2wiPZuKF1Ipeksy/I5oKYRBgDxI6udaNlJNJzvham3qnQ03mF9Zj7jeQxq1c6HOVBOfg745wL9sp1mEIic/3nVpff9XAh9YeQtqi2BTpgBYiUAMLC6Ay9HL9LnDGF0ctb9e+tWrVV8XTGCCwxSUFb4lpmw+aJ9azv/D/LTK6LxhxEqtNk= X-Exchange-Antispam-Report-Test: UriScan:(185117386973197)(228905959029699); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR07MB2442; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR07MB2442; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA3TUIyNDQyOzQ6bk9Yc2Y3ZjZxaWZsWXNscjU2NVJ3K2dmSWdw?= =?utf-8?B?dzlBaFlmSkxONHhpbDVNK2xBSHB1YjA0KzlsNmFWeThVeHdZdWkyaDVhWEgy?= =?utf-8?B?WDJuTzlwL05LT0lRQktuL3U1Mmp3NDlRYTI0RTJtZUdPa3NIN3kyc0hpeUx5?= =?utf-8?B?djFoQWFxWkpQUDdxYU0rYlBEMlBKUFpkMzFXM01EVjNFTFFZNjZYUTV1T2VI?= =?utf-8?B?dUwvL2xZNDFsd2s1Q3hTK0M0aitZaHIrQmZVNkRmMER0M2ppS1lPMXhJcHY1?= =?utf-8?B?UlFOWkhMKzZTb1dBekZqaHJJWlF2UmJpK0kydUltRTVmNHRhdEZXL25sd2xT?= =?utf-8?B?UUh4Tkx1c1ZMdnI5R3F1WllTRmhVVUx5ZnkvaEdLWkcwQXp0VzBwTlJXd1Iy?= =?utf-8?B?Qm5wOUVKLy9XNStBNUM0Mk9nZWNIUW9kdzF3eDk5eEt5bWt4YU41SEluZ2NL?= =?utf-8?B?eTdWNTYwQ3lRR0JLdDE0ZnpGR2RBUDd6Yy82VlZROHlybGVHcGZGaklVNEtm?= =?utf-8?B?RWp6VW9Fb2NHVy9aa3ZmREVUeW9lNzFFZjFqY0ZyL1FMWWNCSjdmbjE4ZVJK?= =?utf-8?B?b1F0aSttSVRMeTlxaXBLTWVDbXV0ZWRGVVBSZTczZXM1bmZtSHN6c1ZyV09y?= =?utf-8?B?cVpyY3lkcm5rY0diaHhma0Y1YzgwdWdrS1BnOHJobGNtT2oycDhscjJHbng0?= =?utf-8?B?Y21oa2NheXlVK3hCdVc4cGp3TGpUd080ZUl3VlpJU0RHUlJWeTNiQTh1WFRo?= =?utf-8?B?dkJsam9EdkpZZG1aRFQ4dFZtVnNoL3czbG1sNXM1bnJQdWF2Q1NidUJhSHY4?= =?utf-8?B?NXBjb2VaYVZuZDhyNTRPd0JDdnhwMEhmSHM5WnErMC9CenpHeUJpRG9uRm5P?= =?utf-8?B?dzhGUmU2dUdxZG9zVnM2QlZWbENvRGxOSzc3cEdIOVU2U2ZHQjkvK21VS292?= =?utf-8?B?aWJyTVVOdUhTU3VhcWxOdEdDRXdlOGczbDBxOEtMeFFFdjdDV2lvUXNRaUNm?= =?utf-8?B?WjNUQ28yR1JSS28zdFhxeFc4TGlOcEtNeEMzVmF5ejZLQ0l6Q0NmYkhDbXdP?= =?utf-8?B?NS9lRythZ2w3d3VhQWdCcFc1Q1lSb3ptQlMvc2pWb0ZGaEE5YTUrYU9ZelRT?= =?utf-8?B?eGE3Ri9za2dpSVdxMk9DWFN3bFRvenBYdUQ0emd2dlZFdTByNXBsM0g3eGFW?= =?utf-8?B?ZGNsbkJsV2hzVVU4emhFU3lpU2xhUzI0UDR1M0xpckM4aVBMVnBRUDNMTWZp?= =?utf-8?B?Z2xkcmZBampqV2NHclYzNzhabndYMnVZUFdnV2h5VEE3Y0VlUnlkeklVT3hw?= =?utf-8?B?bDlQenJsT2crRzRSQVI3cS9OdUEwVURDMGFrRDg3RzI3NVp2SzBKZWxJN2Y5?= =?utf-8?B?eVdWV1RoZXBNRE9yaTNkVGVsZlJKSU9mbFRsaTc4OVltRnNPMGFyVXJLQWhZ?= =?utf-8?B?S2xDSkJUayt1TGlrKzFJQ2xPQ3VLcmFkeUJVTXozK2VkY09VZjhkSDhiclNU?= =?utf-8?B?V043NE1ld2NydDcrNGlZRnJBZHl4NDNBL1lUNVJUS3BKcklSUCtMUDNiTjF2?= =?utf-8?B?MFRISVNZVXQreVV6K1RteUZMSEd4SkN1eEVobG1GdXJ3TGNFbjdvOTJuS25G?= =?utf-8?Q?wl0bhT5pvH6KUXV6QvN?= X-Forefront-PRVS: 03838E948C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(7370300001)(6009001)(39850400002)(39840400002)(39450400003)(39400400002)(39410400002)(57704003)(189002)(199003)(13464003)(23676002)(2906002)(8656003)(7350300001)(101416001)(97736004)(50466002)(4001350100001)(33656002)(561944003)(1076002)(68736007)(66066001)(93886004)(6116002)(189998001)(42882006)(2950100002)(5660300001)(3846002)(7416002)(6666003)(6916009)(305945005)(25786009)(47776003)(8676002)(4326008)(110136004)(106356001)(7736002)(6246003)(9686003)(83506001)(55016002)(105586002)(50986999)(38730400002)(54356999)(76176999)(81156014)(33716001)(2870700001)(478600001)(6496005)(81166006)(42186005)(72206003)(229853002)(53936002)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR07MB2442; H:jerin; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA3TUIyNDQyOzIzOlRKYVVQQVFWTkUvTWFtRTdKdWp5UkRsYU5M?= =?utf-8?B?WXFsN3dQOFkxTnZBL3p0ZEJ0Zk9lTXNDbU1OMHBxT1M2cmgxM01qeXpyL1hK?= =?utf-8?B?dktrTUVUaU0zQjQ1ZmY2dUF4TGlVbG5JOXZBcEtJQ0Y5WktKc2VJNzRocXBO?= =?utf-8?B?WG5wVmdueC9WYXcxZXZDQXhwRjA0Z1QyT2dDTXdOdXF0dko5dE05blkvUlFU?= =?utf-8?B?dUdabVZZc2F4d0t3VnlQQXpJUUovM05Fd2x1Y1dkWHdTSWxGZTJySzI2d0lO?= =?utf-8?B?OTFUc3ZaZFlLYmY5KzUxTEFYbTcvRHM0eHhUam5XMlZ5Yko1SjNJNVEzekZm?= =?utf-8?B?MnNxeVNMSzUrVnJPMDVqNGZ1aE9uUW8zWEcrRHpsRzBqWndRN3hUWEl3bnND?= =?utf-8?B?Q1V0dk9hU3dmeUZRMHZXT1BiM0MvbHgyWXdsU1RVUllpaEhGeVZLUmVJVUVZ?= =?utf-8?B?Z0VPZFkyTTBKazI4c1RvamtMWTQxNExkd0dvSDRJamZzRENJcHlkSzY4amEz?= =?utf-8?B?TXA0VFNaWStGNnkrUTZZSU01VlpjQU1KT0VVZ1MzT2NuWmIyRkFZazZnMk5P?= =?utf-8?B?azQ5S085bWpvdWRMSmY3bGswbjRPODE3cElvWEw5UHJDblFsSEtTTUdubEc0?= =?utf-8?B?YmRIRktjcjJCTE9WSnZNU042S1RmNUxOaFRBTnlYeFI0SzNXM1NnY1JxSmFN?= =?utf-8?B?OWJ0cGtvdEtpTER1dHMxRmZISis1ZjN1bStFTkdQNGc0QnNwenFVR0pZUXhK?= =?utf-8?B?N3N6Y1A4bGh0QVBJWXlsd1lucThzL1RXYVhqYy9kQXg0akhFQS9PUlZtVGVB?= =?utf-8?B?c1d2eSthVnFCakR1TjJTQmhwS1pHMjhXL1ZkRjNVZXQrSFp4K3lnbVVtNXBZ?= =?utf-8?B?eDRNbS9YZ3ZjbGZiZ3drSkpKeC9JN0hZM29lYkpVWThNWGtXQS9od2hnakJh?= =?utf-8?B?NW5weE1BbHBLUGtDK2xadUo4aWcrN0xTS1FRQWZjZjRhdHNDbHZZcEFkTXA4?= =?utf-8?B?dWx2SFIreGE0TjBjMm5PNFNOTXkvYmI3anpaVTV3SFAyck93a3ErTVN0MkFH?= =?utf-8?B?OVF4MFhVSExuVm5ZbEpIeWcvV0J5aFZiSEJYMnljS2NrVWp4WUh1MnBwTVZS?= =?utf-8?B?ZHo4NGdrdWpVVTFTMU5SNk54aHk0T1g5VUtmYWdBNGM4dG5HVXkzOGNxNEZk?= =?utf-8?B?MjZUWmt4Zng1ditEVk43bTVONDRlMFFXS0lzUHZwcVVpMVl1VjR0b21PM1Fz?= =?utf-8?B?TFNhNUVoY1lxUVREOElyQzgybkxTQUZqRzdCeWYyTXg1bjNNM0RId1JRN3ZY?= =?utf-8?B?SGpoM3NSSW90Q0FmaC9RbEc3T2hjZUNnd04wTVVmZTI3ek1ONVpoNktDdnox?= =?utf-8?B?ZkJIWnhxM3JESVF0bTFJOVhOVzJnRFhaeWhiay9nSkJ2aGkyWThwbEI0Mkwr?= =?utf-8?B?cGNTa3RBRjZzWnNSYXRRbzN4SWNSZndtQ3pyU3FtSlhmeExsRW55a3FpR3N2?= =?utf-8?B?QXdIZStla1dmc0FRRVRCUHgwRjNVbk1va25MTkQ0UDFVOEdleUhjQ1lkM1dI?= =?utf-8?B?R3BscUJERHRzaGR4WUU1MGE3LzRDRFBVMDJNcWw5WklOempnemFaa3Z6Uk13?= =?utf-8?B?TktSM29BeUcrdEFXRFJPWlJKb3NWdVZFeWcycDg2c09vRzYvS1RSVnF5SWE5?= =?utf-8?B?eGJsZUF5cDJUNStiOUpiRGlCVkdQeWp4WEptZExoWEZCdjdscks4SjNUV0o0?= =?utf-8?B?bzV0TTRZQlBpNHFqcmovMzNpY256NXJIdU5nbEw5MDZJQmJWOUpSSlNRTVdx?= =?utf-8?B?NHJrMEZmdHZBbVZlUDF1SmNyUWp4NVZjcmxSZGhhYzhUOWNLSzRuVXZyK0ZC?= =?utf-8?B?dWgyM0l5MXNveEQvbFVyWk9XSExqajJwUjZnaE5BbmY0TjExOGlYMHBxRjRU?= =?utf-8?B?aTNMUDlxaFUzTTFJczFUaFRKQlRUQkhYL3ZYWFZhditTVEYxaU5ZR29YV3FE?= =?utf-8?B?T3kzMmg5bFNCVHE3cmp5bXFGWng4V0ZpWHoxN2hhaW1Eb2dXRVdxMlFxcWhH?= =?utf-8?Q?7wfWIquTYBVRwdXWB2PlOArAb?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA3TUIyNDQyOzY6blFoOEZJQ0orWGprditvOHc1TkhXd2ZhZCtr?= =?utf-8?B?Ty9PT3lBdXp6UDFCUkNheThUK1d1ZWx0ZUJib1B1QStpcXJIRmgwYXBzQWx3?= =?utf-8?B?OE4yME5xUEJHeVBjOFM1d3I5TEVFdll2eFdWdnRxNG8rMjZUOTY2ZlIrdFhh?= =?utf-8?B?U01BZEo3MVkzcXdFOUJaRTBvZnlPemhESFZpd3IrSXdBMk16SFFNNVNiZkVk?= =?utf-8?B?b0grem9QUU15czlsRHZSUXFENXRpS3podURick5wVEdValBMODJ3dnJWbHlm?= =?utf-8?B?QmdkYUpwLy81bzdmemhtZ2JPdlcxTGFpc2FXZFArSEVJMVZ6NU90N3hiV0dV?= =?utf-8?B?Z2tNK2RHUk1uYlIreHZnUEdpdmduTVRDM0ZYeWMvL3BVVXc2VXZZVGVHdDV0?= =?utf-8?B?VFU2YkJKM1FUS3hvbjlERExoKzdkSSsydlpHWCtPNnRTNldWWnFjSUxYa2NK?= =?utf-8?B?TUxSS2ZsaE9pQzFCajlybDQvS0twM3R6RllBZExXVUZjMm9Oc3RoandBVGR2?= =?utf-8?B?SG1kWFIzMnJwQjE2eDI4QzEvNnFUMk5vZFBjRGNrUWIyTUFiSGcwWHZabS9G?= =?utf-8?B?N1dlYzVsc0dpUWJlaWpkYjN3SEdLaVA1S3BZc09EVldRYXpjaHJiRHFMbWpa?= =?utf-8?B?THlTamhWaGd0bzFpNFZteTEzWDlOMW9qVDNvYmVQZEdLSmxhRE5heCtrSnBk?= =?utf-8?B?SngxU2NNMVpJZTU0VHpITjQ5elY2ZUNIUTVBY1QxVGZkVlhCbm9CVUd2SVpP?= =?utf-8?B?RVVEVTdlVFphK3B3Zm9CUmtKTmdldDZzSGV3UWRPSjlHbEsyRkVSaFl3TVdq?= =?utf-8?B?azJTOUVqV0tpMG5obWpzTDBMTmppK0F3MEE0cmVGNHpLQWl0OGp2M1ZkVk90?= =?utf-8?B?KzR0WUFYcFZjcnppZkVKOHFZZG5HQ0p3WWZVc3BDUzAzaFBueEZFRWJoUUM1?= =?utf-8?B?UlkrYkFVWmtMZXNWcnhCR2lvelBRRG54dDRoVGcrK2dsdHBHeW1yK1F2cU5m?= =?utf-8?B?TDRUQWRFTjRjMEx1dk5LMXpQSGtCVHFhYjdnUll1MjJac2ZSOXc3aWtGL1JM?= =?utf-8?B?UHFESHFTRzhvQi9rRkNXV09xamVwa3ErQ0wzTmY0WFNQNmxsVm1SU0M2TVJT?= =?utf-8?B?TFdNM0FBLzVEc3MzUVZwN1lHcTJDUFdTclNVRGxmTWNKc0ZQei9mV3ZWdjVG?= =?utf-8?B?Ulc1cnBhVk1MbUR1bitxWTdpdDNBY2xZWVc0NjFQWmRkekplM0UxY2Uyay83?= =?utf-8?B?dVI5dk1FanAvOXN0NDY5Z091TWZobnhmb3RhbUUyWW5TL2pLUStjSXFmdmJK?= =?utf-8?Q?nGgGfEK2MhsnXnv+CORu76wZL6jOvnw=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2442; 5:S+IwStI002F66DI1KAqtCTJPJXfUuAeu3rqMABFqSbwCIlbMwTp67MzNtJARBgC1tjr9fNQ8hWB3ugoB5YJ3H8xJmnK1kFfYry+B8FwRYUb1eJuAmniN9Nc4cQQ2Va/MlkBg6RMp1T/Oaq0iQ4AxHFJW/yJeC6p+4PCUiKBCSLzR+AyngHYxg5JKOd+g3VmpVZTTgy1X61JxnhP83/X7f3s8KwecyhaBsF+mzEwTMPIbjP4EwpuSW8X0wbrooVVbLv9iiWm2FiUwe1uJpNYvrpffo/564kV1O6MztlzzbW1yIt9c1MkSPtT/3y01pUIKZO0N1Fes99OqJleysq1D71g/E05qKv9WR91B9WvNPL46HTdVQA54ZzOi10yeT+MvmQxDW5ug0xH6K9NYCgMoD6OjYTX4oGy5+oYwYAxybXcIDytL32qtju77p1sbLs9MMxsWz9g5PLAl8seS1nPUE/w+7kejlLl2uDzzkKebwhESdgF5Ad9rJunDvSxuOEJJ; 24:6h2Nz0l+s+6MSwb3M3abZks89w+VW2VQOTQOi14tNF3XuW4KBhIuPXoVO3Kn0+GJ/CDFYIKlxtEbcrBsRmpZknlox5G4NqAW5yhav95+Seg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2442; 7:vQG8ey+SgoLfA3Mes/zO4KXR8cjKRolPR1Dv+S3EHc86Iyh30xl82R9OxkGgdQ4bzR7hnBBqVNh/OHygU5Ct/Z9uXypnHaV4Kyqipidkt6eC10pyhDzQl7hEVwavWDkNRLbgfmE/bguM2b305AgX6njPR/+N/UWOYbgHzduQdF0eHtuIzGZts0gaMLH7KAHsdvzC8Jw2woNbUG4lM7NSDzumggNIx8B7yfcreaAkO8ti+pindjZoL4OOr/xPSD8aDxF0fGkMEc8jGQCeXbDu+iz7chje9F/QbUJ69Zjo02WH+QTkW/JUFBzfJkb55izpbY61dQ9HNa4kkIvs5My0oAUhXaxEusMmOB6WeWQGo1BUddjR/Z5sg5wzK93WHQOn0RFiFSlgh7JRQJ5NX/CFgXtaveUEGsFvCzs31F6v8HAt1kLXDwy+LMMt8Gyk0vynGoFM0PKByHVnVcQNmF46sCLzvFEfGc22KQtlP6SoK3XboIuHuoIganQKQ0czf0MyITy+nnpXgWDPPcWWsDzUNwCZtCAmhulsPSekBVZJrW/7LYwq1Bvxri/uxCkBDxdxOhqvvng+gWgR+PuV4jHtu1fkDgI3HyRXcEnHJbEFJHO0nxk4cOK8f9u8xu3rWpI2ypRuVpdCIBqCqJqZ8K2WOzCcuSUBoB8PAm5V/0/4Hub9HJKQwvCz71TvA09X1aTLxrQIrh3PPSwOSzl03205lkaN9mNsCjN6huK0wlhqEQXn+bnUuRBrwtPWbiYXMAB5CkFqOuWs9rIiFMcNncE+tlttlW2MpHUOSjyns3czGWk= X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2017 15:13:09.9502 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2442 Subject: Re: [dpdk-dev] [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues 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: Sat, 29 Jul 2017 15:13:16 -0000 -----Original Message----- > Date: Thu, 27 Jul 2017 16:28:29 +0530 > From: "Rao, Nikhil" > To: Jerin Jacob > CC: gage.eads@intel.com, dev@dpdk.org, thomas@monjalon.net, > bruce.richardson@intel.com, harry.van.haaren@intel.com, > hemant.agrawal@nxp.com, nipun.gupta@nxp.com, narender.vangati@intel.com, > Abhinandan Gujjar , nikhil.rao@intel.com > Subject: Re: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.2.1 > > > > In the case of a SW thread we would like to use the servicing weight > specified in the queue to do WRR across , in keeping with OK, then lets work together to address in transparent manner where it works for HW and SW. > the adaper per model, one way to do this is to use the > same cfg.service_name in the rte_event_eth_rx_adapter_configure() call. > > However this creates a few difficulties/inconsistencies: I agree. If we are thinking about WRR across then above proposal implementation creates inconsistencies. On the other side, it create challenges with HW implementation to have unified adapter API works for both HW and SW. > > 1)Service has the notion of a socket id. Multiple event dev IDs can be > included in the same service, each event dev has a socket ID -> this seems > to be an inconsistency that shouldn’t be allowed by design. > > 2)Say, the Rx event adapter doesn’t drop packets (could be configurable), > i.e, if events cannot be enqueued into the event device, these remain in a > buffer, when the buffer fills up packets aren’t dequeued from the eth > device. > > In the simplest case the Rx event adapter service has a single device, event port> across multiple eth ports, it dequeues from the wrr[] > and buffers events, bulk enqueues BATCH_SIZE events into the event port>. > > With adapters having different code can be > optimized so that adapters that have a common can > be made to refer to a common enqueue buffer { event dev, event port, buffer > } structure but this adds more book keeping in the code. > > 3)Every adapter can be configured with max_nb_rx ( a max nb of packets that > it can process in any invocation) – but the max_nb_rx seems like a service > level parameter instead of it being a summation across adapters. > > 1 & 3 could be solved by restricting the adapters to the same (as in the > first rte_event_eth_rx_adapter_configure() call) socket ID, and perhaps > using the max value of max_nb_rx or using the same value of max_nb_rx across > adapters. #2 is doable but has a bit of code complexity to handle the > generic case. > > Before we go there, I wanted to check if there is an alternative possible > that would remove the difficulties above. Essentially allow multiple ports > within an adapter but avoid the problem of the inconsistent > combinations when using multiple ports with a single eventdev. > > Instead of > == > rte_event_eth_rx_adapter_create() > rte_event_eth_rx_adapter_get_info(); > rte_event_eth_rx_adapter_configure(); > rte_event_eth_rx_adapter_queue_add(); > == > > How about ? > == > > rte_event_eth_rx_adapter_get_info(uint8_t dev_id, uint8_t eth_port_id, > struct rte_event_eth_rx_adap_info *info); > > struct rte_event_eth_rx_adap_info { > uint32_t cap; > > /* adapter has inbuilt port, no need to create producer port */ > #define RTE_EVENT_ETHDEV_CAP_INBUILT_PORT (1ULL << 0) > /* adapter does not need service function */ > #define RTE_EVENT_ETHDEV_CAP_NO_SERVICE_FUNC (1ULL << 1) > > } > > rte_event_eth_rx_adapter_conf cfg; > cfg.event_port = event_port; > cfg.service_name = “rx_adapter_service”; Does application need to specify the service name? IMO, it better a component(rx_adapter) defines it name and format and expose in rte_event_eth_rx_adapter.h > > // all ports in eth_port_id[] have cap = > //!RTE_EVENT_ETHDEV_CAP_INBUILT_PORT > // && ! RTE_EVENT_ETHDEV_CAP_NO_SERVICE_FUNC > rte_event_eth_rx_adapter_create(dev_id, eth_port_id[], N, id, &cfg); The downside might be: - application has different flow based on based on the capability. Listing down a few capabilities/limitation below. > === > int rte_event_eth_rx_adapter_queue_add() would need a port id in the N>1 > port case, that can be ignored if the adapter doesn’t need it (N=1). > > thanks for reading the long email, thoughts ? I have bit another thought to solve the above mentioned downside. - Theme is based on your original rx adapter proposal but with eventpmd ops(not adapter ops).i.e Reuse as much of your existing Rx adapter implementation as common code and add hooks for HW based adapters. For example, before you add to "rx_poll" in eth_poll_wrr_calc(), Check for eventdev PMD ops is available adding it HW. If yes, Don't add in "rx_poll" adapter_api ------------ int rte_event_eth_rx_adapter_create(id, rte_event_eth_rx_adapter_conf *conf) int rte_event_eth_rx_adapter_queue_add(uint8_t id, uint8_t eth_dev_id, int32_t rx_queue_id, rte_event_eth_rx_adapter_queue_conf *conf); eventdev PMD op api(not as adapter PMD as discussed earlier) ------------------- 1) typedef uint64_t (*eventdev_rx_adap_capa)(struct rte_eventdev *dev, uint8_t ethdev_id) Return the adapter capability of a given eventdev when it needs to connected to a specific ethdev_id Possible capability values based on my understating for existing SW and Cavium HW PMD. NXP folks can add new ones. - RX_ADAPTER_CAP_INBUILT_PORT - /* adapter has inbuilt port, no need to create producer port by common code */ - RX_ADAPTER_CAP_SET_FLOW_ID - /* adapter capable of setting RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID */ - RX_ADAPTER_CAP_ADD_QUEUE /* adapter capable of adding any specific ethdev rx queue to any eventdev queue. Some eventdev PMD has a limitation that once a < ethdev_id , queue_id> connected to specific eventdev queue, all the all queues_id under the same ethdev_id need to be connected to same eventdev queue. aka works only on the rte_event_eth_rx_adapter_queue_conf.rx_queue_id == -1 mode, */ 2) typedef int (*eventdev_rx_adap_add)(struct rte_eventdev *dev, uint8_t ethdev_id, int queue_id, rte_event_eth_rx_adapter_queue_conf *conf)); -- if implemented by eventdev PMD and returns zero then COMMON code does not need to poll */ 3) typedef int (*eventdev_rx_adap_del)(struct rte_eventdev *dev, uint8_t ethdev_id, int queue_id) -- remove previously added *** Haven't spend a lot of time on API/macro name.Please use better naming conversion. Another notes based on your existing implementation + eventdev ops scheme 1) rte_event_eth_rx_adapter_creates() registers service function by default. It should be delayed to when common adapter code find a device with !RX_ADAPTER_CAP_INBUILT_PORT cap on rte_event_eth_rx_adapter_queue_add() 2) Do we need rx_adapter start/stop functions? 3) If it happens to be case where rte_event_eth_rx_adapter_queue_add() use only RX_ADAPTER_CAP_INBUILT_PORT then common code should not create any service. 4) If adapter uses one port with service core and other one with HW adapter. rte_event_eth_rx_adapter_stats.rx_packets will be not updated correctly, We need eventdev PMD ops to get those stats. If we agree overall PMD ops + adapter API partitioning then we can refine additionally eventpmd for stats etc or xstat based scheme etc. 5) specifying rte_event_eth_rx_adapter_conf.rx_event_port_id on rte_event_eth_rx_adapter_create() would waste one HW eventdev port if its happen to be used RX_ADAPTER_CAP_INBUILT_PORT on rte_event_eth_rx_adapter_queue_add(). unlike SW eventdev port, HW eventdev ports are costly so I think, We need to have another eventdev PMD ops to create service/producer ports. Or any other scheme that creates rte_event_eth_rx_adapter_conf.rx_event_port_id on demand by common code. Thoughts?