From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0044.outbound.protection.outlook.com [104.47.40.44]) by dpdk.org (Postfix) with ESMTP id DA822968 for ; Mon, 12 Jun 2017 14:42:43 +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=Z1mot8qL81W+V0xJCtLP9zRJX+z/1GRprqo17//PwMc=; b=nSWLSJ5j4HMT20S8EK/+Gp+hhnU6EJ7cacplMt8a5cC7g8eNm3S1g5d2tOsXKNvCa5/rpu0KU6viS/WEuTwnQka1IPRfJhZSKLD0Snt7hEih/w3tYnRufcP51zN950/YDXCW6WgcaMag0nsXuC8zIYWQJGPmVx5M67cUreiHPQE= Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=caviumnetworks.com; Received: from jerin (111.93.218.67) by BY1PR0701MB1721.namprd07.prod.outlook.com (10.162.111.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Mon, 12 Jun 2017 12:42:38 +0000 Date: Mon, 12 Jun 2017 18:12:19 +0530 From: Jerin Jacob To: "Ananyev, Konstantin" Cc: "Richardson, Bruce" , Stephen Hemminger , Yerden Zhumabekov , "Verkamp, Daniel" , "dev@dpdk.org" Message-ID: <20170612124218.GA20971@jerin> References: <6908e71a-c849-83d3-e86d-745acf9f9491@sts.kz> <20170609101625.09075858@xeon-e3> <20170609172854.GA2828@jerin> <2601191342CEEE43887BDE71AB9772583FB07AEC@IRSMSX109.ger.corp.intel.com> <20170612030730.GA6870@jerin> <2601191342CEEE43887BDE71AB9772583FB082EC@IRSMSX109.ger.corp.intel.com> <20170612103409.GA4354@jerin> <20170612110907.GA64736@bricha3-MOBL3.ger.corp.intel.com> <20170612114117.GA17595@jerin> <2601191342CEEE43887BDE71AB9772583FB08394@IRSMSX109.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB9772583FB08394@IRSMSX109.ger.corp.intel.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Originating-IP: [111.93.218.67] X-ClientProxiedBy: PN1PR01CA0101.INDPRD01.PROD.OUTLOOK.COM (10.174.144.17) To BY1PR0701MB1721.namprd07.prod.outlook.com (10.162.111.140) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR0701MB1721: X-MS-Office365-Filtering-Correlation-Id: 31cc5e0f-885d-4c5f-e523-08d4b19083d8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:BY1PR0701MB1721; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1721; 3:KfY69ygijotPGvFUF97FIUdgyVSQl3yzs/x8+RyfrO7j6y2Bo2OvV3baszd3PD6yndnq2VtJgygOIOhi3+MoQA8AYtWv67KSY9bbr7L22asYjn4PIwdFEv1dzvMeD1mE09NQ/OBt7HyHKfTZfbw3coFdZO+w7OZfw/MyqGGzi0pPvh3DL7KmUQ6+cuWCH0jFB9hIfNnyB+V9ZjdSUaUopXDBOwfA5mpw8LdrP/FEO6omYPy+RhbMXxDGF8lO36BEViOCGx6xC3LT9Z7tXTo70ctqEm4oVNwfCOnp3fCIwxLqWIFi4h5GL9qbiRxF0B/jXOAYpz5ifmzHwdhzDadHEQ==; 25:GvZCHte1IRYgC4FxplvgKqY6WPzQuUhvpeQNcuN5Enm85Mc4Dj8g5OHk2zohkjHm2aVR0zhhmMDmQmaUJp/k2/TJRvk+aApkXXnf0ZOpltmAIk2pBCVdqeWoGpqd9LC2EwNeFWW/JrVAPn+Yp7b27Tj5yz681FRszEoZsKPhYb8V+ngRTTI7VvKQh7pS7u5Hm0X6pjUL7J3Xu3Ysi/wHAu9T0YLF4FsbZOdcjv6Wzm7JCE+BKmEaOpUEz2oeOUjpdpw9QXJes3L0hCgBX11A5OCgOT7ZO4mUwXs4SynYqPHw32jIVRPytTzKyVbUx6Zhs2OFlh54XifK0hXeV09ROBrUoTtu7XmmwQ1d8VkAKk9BjEk7sapNQ/T8GygTTW4Wx/deUlvwnOH+TZxJocpgC7uJ68jYM+/60z+lbQwJHaRp1O0qdseWqeiHqpx9vD9umSvqPrgS5jtzWdrYNzPVbVF34/Ra5fVG+MudtKqs6sk= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1721; 31:UbkMH09Vp5jJTi+FN7W3rOwNXy6jJRhNn2uXtADdUnz+zn4DQy+mtRBg41XAdushoCVr2nSC8v4AU3iJ//z2SCYnAKLl9gCZwdZ7mmfvZ9/xVm2lrleDx4VGo8Hw2K8zfSwi61kUpYlNpNzWE+Uy5TuS4gGwmy5SmIaqY90aj8DRvwGKFk91/CKEW4KLafRN5/AKOLdJwGFD7IsyS7MfsMkJVCXWt4JzEHPgOa2oJ7cDRxGInu1fgL9eyVzMapBu+qpYd2nx+CY11IgbUz5y3A==; 20:qBDS+JoFnqbvhDwBqVlbJbXh3kaSAO7CEGdPr5JNAszcX3bi1VMJR3nosVuM8tuI8lfByCsAfDDB4E2zJ7RwP5V//cAD6/DugMvengt/f0Z+eYmw04yq9rcmZDXh59fTHW+RTzZa2tVeQyX0s59Q5QhIIkTcRDt7YRzxnI3tPmaT0OBFLQia/NqfXhONmMfxvkdaxnsi8AYiOg3jv5uJd26VA3LNNGi4WE5diWlhytWBv2R1dZm/jNB7ABAhSzT4YtF8K10UJ+a5TfgORGcveFsvGZIItQf9cH9KeSJGtvIwIwhdUQpnZbTsmaq9hNegveSdPrB8iUTYQ02UfXopNCZXI90cRq8Kxexmj+i67ePZXyPibkFlWC6Z0kPAfxyF/FaDmVJuVdwVTKJGsLfA4VF2LOklVkgj13X0QfNh1GTKrRGyoAJMxzMjg/4Du7a6Fe+i3HI+pkydBErWlSMFt1sELsAGuTxerpw7AJX8400T0LDcoxKukhXI8GoA/0WTSGJxi+Qsab4Ox19CLezJjx0Iz4ebCpOhE0Z38n8z+RYr8gAGHs4bPJ+b+mMujePk7zuNUnOY3ThSRJdKrZ9/iY5wzwvO7YoL+bUk7THTk/0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY1PR0701MB1721; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY1PR0701MB1721; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0701MB1721; 4:XQcKNyja6J6lW0W56mzpUt+SD2NPvYJ5gpnMvvxe?= =?us-ascii?Q?olXXE3h4V6GBGy3PCyVuHr9BD5Dns+yGwG+/mHcH+Fd86y2Dam/V2u/xw63Y?= =?us-ascii?Q?L72vzP/5eUXIkrxS0iZMQpz7vs8fGZdFgnt/5BDso6IjXAwPvziPzrYzCF3z?= =?us-ascii?Q?06VMrXjlwF0AylmOSI0EM3CQ5DQ6d2AYa9eIgZAwB/izfu+6I8GWLL3Q4Hf2?= =?us-ascii?Q?sH+GvuOQ8EHvXOUERpu7K/O84Nimgl6RradYyQ20uBDNll8cHyvFc2y3OBWm?= =?us-ascii?Q?1vg2vvITsAdfGW7FjJWtN0k4q3ljCAiywWqrmSACu5bBEkP9vHvQ4qushRi2?= =?us-ascii?Q?S+FO8wvgvD5jCnGMEdTMktojYpzYYwPG9vPJMAkIkibm8FAv/5uFbjI+8NI2?= =?us-ascii?Q?D7PR5RTGpXnvf7HeSDH/LlwAC2mFrTdwq4GPQwVmm729R6l/OaVAiBT4Ll7X?= =?us-ascii?Q?rwcRoFAmvy89ToJngQYrZXyNVbkAijfNT9SRu4Ui547q9+crNLA7v92EqVBe?= =?us-ascii?Q?pqivsE3lszj5lLhX0JuaMHa5tgxq0+H4h66/baszlre9jC3RDc19Nuqcs/ro?= =?us-ascii?Q?g8YGat4UakiURbBF6sTFa3SIsytohXy9y6Q8j6ZACRrMpO5eRjDiba+MU4rz?= =?us-ascii?Q?dMj/+zPsvFsmeCxiQcW5fLj0F5l8AAQKXJqQ6D7qSmgVFlsBUuuvSuCf51fm?= =?us-ascii?Q?Kn+c5QSqgNlaT3xmn9APfDvviTDV5DZXQVg97APfR8uB5qPiIKH4d0a42sUn?= =?us-ascii?Q?jw3GlirrIdqjSf0zlk7M2zM644WJKPutPObFEmBZGHWhlcfZomQGW0xxs5dh?= =?us-ascii?Q?Wy6vwPyrde8LzZtJd6b3e0fEtCm6EVNmn/0Y+aKT2qCQryAZty9TJ47TuA08?= =?us-ascii?Q?CZWxVFOHDI7yFE6mfNIwYzTCZlJxL6B8uKB6Dz/9xCLZTSHRq8/FUqoO5+FZ?= =?us-ascii?Q?0QvDAv3E0FDWejacVsof7fY2cQ/UefknTfQomCxls/LipxV183WDOj8qo8TU?= =?us-ascii?Q?TRm0QdLGeZ4JNlrsMCfXWK1NYFnI0i0590pTz1h3MEjy6KFkQ/KuChEjxyXg?= =?us-ascii?Q?AyTNLNmuO7gO2a21/iWNxdoZV89+NPGZ2ihiioMYVuaEr0p3x+GcHuaOrfn4?= =?us-ascii?Q?0w133asKgN40XspJn2b+BUYCD3KZxMY8p9HME1HuPqUZIPEVQTq0OQ=3D=3D?= X-Forefront-PRVS: 03361FCC43 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(39450400003)(39840400002)(39850400002)(39410400002)(39400400002)(377424004)(24454002)(377454003)(13464003)(6666003)(72206003)(81166006)(478600001)(7736002)(305945005)(1076002)(8676002)(3846002)(5009440100003)(23726003)(50986999)(76176999)(54356999)(25786009)(4326008)(53546009)(93886004)(38730400002)(6916009)(42882006)(53936002)(2950100002)(33716001)(110136004)(6496005)(6246003)(55016002)(54906002)(189998001)(42186005)(9686003)(33656002)(2906002)(229853002)(47776003)(66066001)(5660300001)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0701MB1721; H:jerin; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0701MB1721; 23:QRMDEwEsjlpKbG6coPElfwo/uIej3Aoex7oBgkZ?= =?us-ascii?Q?u//YvjqhcJ3yGkdW1m38HTPaUV0PHPF+2rqiQdvq7hEI8OMLoOJ10BF6tlLy?= =?us-ascii?Q?bXCzgBMLB6IYChsjxHOtVuUaW+eC5EXq1qvlE7ghhMWcSfAjGgZrJsng6+je?= =?us-ascii?Q?/b7PhIlHPJ7RQksjiqb5r3QCnoLub893+yeytR+OBPl8JFLWmWV44cx3QMdW?= =?us-ascii?Q?YPlBlrQ19AQsjpQXhqb3hikn2T93UveRkWls8b8dZ9ZWbXNRIlZf6HX117Le?= =?us-ascii?Q?ExRGdJ1za2LssU3zyZDg2LmXC2OHJtIjcXcNVYJoAakbLEhPnLUae8rlPygP?= =?us-ascii?Q?wyrrRCJ4NOan259raZ3w2alhEl2SAFICE3mwB1VJMLQPBotnt47PItcvSDF0?= =?us-ascii?Q?/maaHx/I9JNySnAB+WyK6k58ERnwTu7WUFvKaihunRRuIQmmv12tSkM/GDRP?= =?us-ascii?Q?Atv8PE3e1WrqMup6tj5UXsgT6f/nl5AHSSh/KuRVhfQ2uRxgu1AAjCGHxn9A?= =?us-ascii?Q?3/hTZCavHa8jwezCSNvg53cQpw9ngmg34FFXPvq6esaCNkMpftA+AaVWPsWX?= =?us-ascii?Q?q0GLvjGSIhuirP0O3QZZMkFymnNF+OlPe4z3KTP5tsorDX7dt+93fGZ7nETM?= =?us-ascii?Q?AxiNc9r83tgft00epqIpDHGJGs80E9vvkLoAQNMx00y9VPzBmz+y1mwT9rcY?= =?us-ascii?Q?KKSHDc4AETJRCEhcy4e/w4uhwCSVgHWZRUpgjQi6lRzMd9T9fo56rjaiSram?= =?us-ascii?Q?kizxWkbjUsSs3wLjuZIWSXWj/dXCOH1HgJw9/ouM/JmPd132YsNuZ4Ek6qlz?= =?us-ascii?Q?PJSwKcnFhIy84e40ZzLHfpofEJ6nHZgDg5tvZlpBThXGbi32eC4dOSGT+T4d?= =?us-ascii?Q?PXmOOlufhBxup1cvZ4oObB+9l3CU4NKmIzP2f9YgmbAw08pV45KN8CCdxmY8?= =?us-ascii?Q?dqnLpQQYKldflVzqXDGrq75m9XzstaYDE42T3CWsGOLUVoouLAXEi1Kpzu9o?= =?us-ascii?Q?/Opw3AEy+SEA0hHv3qn68rdk8ZjdqCSLdsHh4qkWe0zLttfWigVG0nB9tvQC?= =?us-ascii?Q?Wb1P1Jp3t3CukJBtbgSuYXyInnz7rq5KZjV5BqufDtNdDX4zsHe4qGtcWFp5?= =?us-ascii?Q?/Rgqr3xSCluM3D0w0bcaEnDs1EBYzFO6nLL9RiAdg53C0jySbJp6ktOddI0z?= =?us-ascii?Q?eumbsHZAIzeUz9+83JrRfUxJvh6H1eQghqKb0F7ESGMdyRkOR022Wvgkgv2f?= =?us-ascii?Q?4qKYzlkvQKRgXlJoyyh0=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1721; 6:9Ufo2o9h+meOxYqydLkesWPVytM3GYySnhmUM/AQhaSEKdTALxDW4nPRsCj+JdjItyheID7C1K9ccyfxbkKSRgY8OFRnYouWGx3h82ssadPF78g5seLqrW834SoBji3WgtxF+/7YgYuwVXHmTrD9SEv2skdpQSsZlpOKoESNr7fKNpd5aa6I9qBbSBvLpq3WMZKMXK64Cpb+kF1VFo/cOs3YwvT6aTQiiL2T8xoL9hSCluM0dzioBTP5Is0At+7zlbg425k65fLzVoUr2I+5snXQBto/jIHAmVFOBeupHkfBCv/olzuFpSyDoxfTa/2R3vQePlNDzJmvEhuQisrnfYGEmJEL8Pm2u32gwoDSMSgjx/YxEwpYiBfkMilecR2vrl5mG1z/EqnnytETfD7qjFgRZ9laI3WjLo3qVX2Ri0jplcFVY49ldUq5pZXcw9uBhT+fwG/aS9HB+fsl/NtCtK+zEITmUAa/jF+rVfGzqHjJm+OUf0pgsxVwbVH6UaWI2v0joEXFaABtHhS8IKvHzQ== X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1721; 5:WSrG9n88il1hXDoe4K0442cebv6yWy66nz1WFwcN0jtB2iNHyUQ/hcpMR0d8LBSCcYV1zVqriIbA0/ir+q742cy08aFkkBM6zOYrxivHFat/nDL/YX4ZDAvtbpgbYZki0rRWGn+uozzOI6qEFqKlLgT1kqnG7MOhJdAbWnIqPVdPLv9iB4BWSwzYJQvja0nKufYC0wCIa7ywQRTIv8dKZDGba8Y2kkuSGmXVZLKYz7F+6ZdhyoVuembne3G1YGKB6hkfQnTI2ve/UIKhIaIBdH8+K/1k6ja6t0uDA3H2c6cG1SGkeJDS7CcCScY3N3mfh4pc9CGYlc9Iy7piXKoJZqkES5Qf3/V9gB8S88yuJxnM9TDF6J3TJ7ubf/MP98LtAIXwyQT8qdmCnu4wdh0cEVRU4DNiahTGQ+k6NicJsjAPoRJMtw/XpIllBQ/9OT81vK5woyfhDaQOxPNyIcd7qOTxAiqGKr/qdKboR56ouRS81XIcsyZLMMdOfH/BDf19; 24:RB8UfErP2hG9fqjsDXcGRQWc84YltJE/K8K4EPGdfgdgIW/cPq3A98qvOgBH7QPCXgyv5sgtdG+Mtpvvdr4RflAuyafpTUpHo/AiGaj15nQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1721; 7:7UTurG/mAzz9CYv/fG8+1q8YJtbJmDInVd7nieoOMk79deqh6TtadBPMldqIOysTz6wkROa835f6MqNIPvatqMsWuNx8aQ7WUPCF4e+RqWleZ3vMW1dgWdKYnF/tkpceWQWIIEQ1ug6YDGrwzKAoO38Da+EeNqiIFJ1WRh6JfbSmuWPj11kQP06XHVkujkePSuWl0PwCMES/N2LOQ60Eamm4Zggx8qW72noOcJ4S87z256LyWW/B4zz7JcPCXY1NRulnDvPsXRsbQJMi9pJMxahXFjxuEVpjTjYjXQGTjZspPZ9tdYvNc9szqIT2sZ2PapYUMsY5xMjcDNcd+LZCxw== X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2017 12:42:38.4018 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0701MB1721 Subject: Re: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation 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, 12 Jun 2017 12:42:44 -0000 -----Original Message----- > Date: Mon, 12 Jun 2017 12:17:48 +0000 > From: "Ananyev, Konstantin" > To: Jerin Jacob , "Richardson, Bruce" > > CC: Stephen Hemminger , Yerden Zhumabekov > , "Verkamp, Daniel" , > "dev@dpdk.org" > Subject: RE: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation > > > > > -----Original Message----- > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > Sent: Monday, June 12, 2017 12:41 PM > > To: Richardson, Bruce > > Cc: Ananyev, Konstantin ; Stephen Hemminger ; Yerden Zhumabekov > > ; Verkamp, Daniel ; dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation > > > > -----Original Message----- > > > Date: Mon, 12 Jun 2017 12:09:07 +0100 > > > From: Bruce Richardson > > > To: Jerin Jacob > > > CC: "Ananyev, Konstantin" , Stephen Hemminger > > > , Yerden Zhumabekov , > > > "Verkamp, Daniel" , "dev@dpdk.org" > > > > > > Subject: Re: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation > > > User-Agent: Mutt/1.8.1 (2017-04-11) > > > > > > On Mon, Jun 12, 2017 at 04:04:11PM +0530, Jerin Jacob wrote: > > > > -----Original Message----- > > > > > Date: Mon, 12 Jun 2017 10:18:39 +0000 > > > > > From: "Ananyev, Konstantin" > > > > > To: Jerin Jacob > > > > > CC: Stephen Hemminger , Yerden Zhumabekov > > > > > , "Richardson, Bruce" , > > > > > "Verkamp, Daniel" , "dev@dpdk.org" > > > > > > > > > > Subject: RE: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > > > > Sent: Monday, June 12, 2017 4:08 AM > > > > > > To: Ananyev, Konstantin > > > > > > Cc: Stephen Hemminger ; Yerden Zhumabekov ; Richardson, Bruce > > > > > > ; Verkamp, Daniel ; dev@dpdk.org > > > > > > Subject: Re: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation > > > > > > > > > > > > -----Original Message----- > > > > > > > Date: Sat, 10 Jun 2017 08:16:44 +0000 > > > > > > > From: "Ananyev, Konstantin" > > > > > > > To: Jerin Jacob , Stephen Hemminger > > > > > > > > > > > > > > CC: Yerden Zhumabekov , "Richardson, Bruce" > > > > > > > , "Verkamp, Daniel" > > > > > > > , "dev@dpdk.org" > > > > > > > Subject: RE: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > > > > > > Sent: Friday, June 9, 2017 6:29 PM > > > > > > > > To: Stephen Hemminger > > > > > > > > Cc: Yerden Zhumabekov ; Ananyev, Konstantin ; Richardson, Bruce > > > > > > > > ; Verkamp, Daniel ; dev@dpdk.org > > > > > > > > Subject: Re: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > Date: Fri, 9 Jun 2017 10:16:25 -0700 > > > > > > > > > From: Stephen Hemminger > > > > > > > > > To: Yerden Zhumabekov > > > > > > > > > Cc: "Ananyev, Konstantin" , "Richardson, > > > > > > > > > Bruce" , "Verkamp, Daniel" > > > > > > > > > , "dev@dpdk.org" > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation > > > > > > > > > > > > > > > > > > On Fri, 9 Jun 2017 18:47:43 +0600 > > > > > > > > > Yerden Zhumabekov wrote: > > > > > > > > > > > > > > > > > > > On 06.06.2017 19:19, Ananyev, Konstantin wrote: > > > > > > > > > > > > > > > > > > > > > >>>> Maybe there is some deeper reason for the >= 128-byte alignment logic in rte_ring.h? > > > > > > > > > > >>> Might be, would be good to hear opinion the author of that change. > > > > > > > > > > >> It gives improved performance for core-2-core transfer. > > > > > > > > > > > You mean empty cache-line(s) after prod/cons, correct? > > > > > > > > > > > That's ok but why we can't keep them and whole rte_ring aligned on cache-line boundaries? > > > > > > > > > > > Something like that: > > > > > > > > > > > struct rte_ring { > > > > > > > > > > > ... > > > > > > > > > > > struct rte_ring_headtail prod __rte_cache_aligned; > > > > > > > > > > > EMPTY_CACHE_LINE __rte_cache_aligned; > > > > > > > > > > > struct rte_ring_headtail cons __rte_cache_aligned; > > > > > > > > > > > EMPTY_CACHE_LINE __rte_cache_aligned; > > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > > > Konstantin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm curious, can anyone explain, how does it actually affect > > > > > > > > > > performance? Maybe we can utilize it application code? > > > > > > > > > > > > > > > > > > I think it is because on Intel CPU's the CPU will speculatively fetch adjacent cache lines. > > > > > > > > > If these cache lines change, then it will create false sharing. > > > > > > > > > > > > > > > > I see. I think, In such cases it is better to abstract as conditional > > > > > > > > compilation. The above logic has worst case cache memory > > > > > > > > requirement if CPU is 128B CL and no speculative prefetch. > > > > > > > > > > I suppose we can keep exactly the same logic as we have now: > > > > > archs with 64B cache-line would have an empty cache line, > > > > > for archs with 128B cacheline - no. > > > > > Is that what you are looking for? > > > > > > > > Its valid to an arch with 128B cache-line and speculative cache prefetch. > > > > (Cavium's recent SoCs comes with this property) > > > > IMHO, Instead of making 128B as NOOP. We can introduce a new conditional > > > > compilation flag(CONFIG_RTE_ARCH_SPECULATIVE_PREFETCH or something like > > > > that) to decide the empty line and I think, In future we can use > > > > the same config for similar use cases. > > > > > > > > Jerin > > > > > > > I'd rather not make it that complicated, and definitely don't like > > > adding in more build time config options. Initially, I had the extra > > > padding always-present, but it was felt that it made the resulting > > > structure too big. For those systems with 128B cachelines, is the extra > > > 256 bytes of space per ring really a problem given modern systems have > > > ram in the 10's of Gigs? > > > > I think, RAM size does not matter here. I was referring more on L1 and L2 > > cache size(which is very limited).i.e if you fetch the unwanted > > lines then CPU have to evict fast and it will have effect on accommodating > > interested lines in worker loop.. > > Not sure I understand you here - as I know, we can't control HW speculative fetch. Yes. But we can know in advance if a product family supports HW speculative fetch or not. Typically a product family defines this feature in arm64 case and we have different targets for each product family. > It would either happen, or no depending on the actual CPU. > The only thing we can control here - what exactly will be fetched: > either empty cache line not used by anyone or cache-line with some data. Yes. If we know a given CPU does not provide HW speculative fetch in advance then we don't need to give empty line. > Konstantin > > >I am not a fan of build time options but I > > don't really see any issue with _ARCH_ specific build time options. > > I think, it is good. common_base can have default value if any platform/arch wants > > to override it can override it.I don't see any harm in proving that support. > > > > > > > > > > /Bruce