From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0062.outbound.protection.outlook.com [104.47.38.62]) by dpdk.org (Postfix) with ESMTP id B193E2A58 for ; Mon, 12 Jun 2017 15:20:39 +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=zaSZHUHsSeKI0j3ERCbdEZO7ehViTtBtjd1/YqyUctg=; b=OGAH1bK4grSaYvSLB8D6/XHiACbSVSWKXSD2v9B2ER7vVzYev9i3Xc6UEqyh5XexTHmNLbWKEgLuhxErwt7qtwrG7DiGBNhBxx23S4Frl70z/uX6QPHk51L54clAGP2ytYR53x4Zwq0vQbdljF9sAuhOC3HhXCuzbwVMjwSSOj8= 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 BY1PR0701MB1723.namprd07.prod.outlook.com (10.162.111.142) 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 13:20:33 +0000 Date: Mon, 12 Jun 2017 18:50:16 +0530 From: Jerin Jacob To: "Ananyev, Konstantin" Cc: "Richardson, Bruce" , Stephen Hemminger , Yerden Zhumabekov , "Verkamp, Daniel" , "dev@dpdk.org" Message-ID: <20170612132014.GA23210@jerin> References: <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> <20170612124218.GA20971@jerin> <2601191342CEEE43887BDE71AB9772583FB083B9@IRSMSX109.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB9772583FB083B9@IRSMSX109.ger.corp.intel.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Originating-IP: [111.93.218.67] X-ClientProxiedBy: PN1PR01CA0099.INDPRD01.PROD.OUTLOOK.COM (10.174.144.15) To BY1PR0701MB1723.namprd07.prod.outlook.com (10.162.111.142) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR0701MB1723: X-MS-Office365-Filtering-Correlation-Id: 8baeb620-a538-4f0f-2d21-08d4b195cfbe X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:BY1PR0701MB1723; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1723; 3:J4mXNSDSAYCM7Pz9IKPON7IPlUWtE2kgjM6QgxdgpDIoFTjJAwOUPvjkIRdK4oEns1mHXricOZH81h8H4UmD9vsoTu/LcKln7DOMM7jL/yngt9u4A9GkLT61vXWFGLyyR3WGVhoZ02ucrMpUkDj1L/4EHg0nkFu7t/MFtK9zi1N1xbucJ29wO1msHLCdNaqqlvc2IjGrzIUQBkBg1VeNm/zjYMLaja3bALEJdNkT0nhuTvTUrtaG56V3uKYiP+9ZPdmtP69KnSia84RzslqQTlKleEN6sGlqAQw0MZa/sj9NcMwH5ecZvd86sixUxU+R9INVvnSynVpYdoyNuQy5gg==; 25:kdv94BxBO81XXsFjUnek3XFQX2FQnduUB/U3zvJdlHPoFNmZJ9tukHMypgs5dHKDnjyAQAhtYPLGf+1D2SL/c7Wcx2+G/hVRN63ZB1fsC6LoLHYBWlnxS8/GkZLtAUQOF6IEKuSfzgXvhy1Rxzn8a3e1nNj46DS+4oaSn3YtSfBlp/VqXlOjqj8U9pevaAV8mS7DjSHZCT+KczPbKZ/YNfzfJZ8W0uRwpasORYWisi/tkWKmCxLf7bSWz7d10QVR7qJ8MgqqJB8q7KUTU42Czh9yxhudpqVuonQ44k/71/o3rI//TpH+ynW+QY1pxrm6xiKzl/ksbdOAnd7jSu1OxgYZvkGcwF11aKmRmAoINKIzhBGcSf4j0kFo5eAJEkeGKjNad4aSoSjWO7AHKCSxzAJDnN9Fk/7hSojl5aGTBTuCVcAHgB6dSgMGRZozi9/CUQ9veI/dPKWFb0odvDz81vJuw5reGl6etj2GiEvAlPQ= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1723; 31:7ii6bXl4AJiEXSXvgr6yhQBYbvgpwOnGvG35A9z8CZ9GTPkY72Ltg71iU65clW0X6TsmScsSeMEsFVUn4PillJ0AdYEmvNMoYoi3s2PQIY78H3r7FSg/qA3pzcjs11RjdV41aiXlxVNmmK08yxv/zm+0CNIkIEizEj65f9lW8T4Viy9ELNvkf7xPa+1FUuMD0xpjMVsOHqhTPwu8CHsc3CkzzuUlQAV48jP/znSiJlYelW58YFl+ZaNwraB7axquDnZICw26R5MVyu6CGmyujQ==; 20:e+Q/sRg18O40bKIlhkbplsGQNy1jbfStuyEknp36niEN5K0jRMJgd+J7TYFkuRpiNfINifrnUgI5SjSj9lJAH01o86cvHpHa1/LzG6yWUiT1HSwuda840NGIy30HWlGiHwEcqLQTYtvIHrpUep0t2aM6wafNA7O5a6C+QYqjT7Md4Jy0U9R8Pd74O57g8sexqOVco5GzJ6FPIvs6nG2smDlYg7Jglp/tUlbyrvjdVgiAAWtUzG7tRdr3MqLPWJlNkZ2eqAYIUhOsBgRDyyyEzHuyR3fJJnQEHG6FZjIsw/RLmyOOK8ORvao/KMCc0UjQ4glP2WDj7L9geLeGVVcbV4zwYIu327DP20KvkiEYjxGf+lpS51Y8rW1k32FhY1CdlN3wBl42pbS02ONDX//IQnVY7kBoxgbJAWixKjVapcAbjPbkJ8se1QAforp4XaPtqx6SIK9dsCGYZJ21Vtlg61E3YZKihuZkFEiGYK83L4TYrp08P3L0FatZ4ubXmmzE9XCkgZVF9y6NoNbmnDuuNyMw4tFe+oB9GcyX92wRhi9FP8wOFpxI4rnImL+jRUTymdkGCuHMG+nsuzyTVTAhw6f0lCWZVCOyWQY0tMHKLKY= 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)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY1PR0701MB1723; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY1PR0701MB1723; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0701MB1723; 4:ygUSnKPqGLejIY6Wm8uYoF2v62YNXtEqk9Lr+NXv?= =?us-ascii?Q?XL+uHtaUxi0+DKEbflvkPgG2L3OSgGuo0TXO/Ls/igiVCoSvO9gvPH1BxP9t?= =?us-ascii?Q?s17rW8VqzURr+WoDlG2jt/nr6jM/lCDtNjWf9kVeVhG/RckDw6iRhXUZ3GQc?= =?us-ascii?Q?I9QFFo7Z6PKHvxCV02LtJRHze29OUuA4ZwCtMmdRAra7y1uVqEqhCjjdl7/E?= =?us-ascii?Q?c6NpfSC5kFXJq9zdgAUA+pyL82rh+z9OtzSV6c0RQWohcbJe6LxBw6xG3rMY?= =?us-ascii?Q?YlC5u1WbTp7TkQsQHgFYZXk6YUcns5NcGAhSApKAOCOs4l6aEb6X6DqmdkSi?= =?us-ascii?Q?2mX1nU/dg2qrgSXQwqwd8B9bt3lOnuY2353RCLx6p2U2M/2q7NGCkS2gT6qT?= =?us-ascii?Q?EvakZIdDPT2s6Q3JMkDLDFqDt4EUdFaGZ37s9TLVusO60TLqsJxRJTpXEtA/?= =?us-ascii?Q?crpB2Jpsegz2mrTpz+nmTEkWKAz2I2Ka7sxUW40GoJdyZ3+hsyl+5TnjAQh0?= =?us-ascii?Q?yCPQO4JHnMwfrDbfIXRWLhhXLxZBM/pM6CKH/mLDliTYsd1Iqd8Lsls7p7Sz?= =?us-ascii?Q?i3RkezJ8TFurMXrfMq72lnePbnor7k5EnB8Gt/9EgpO6+WiOaIZJm+S10Rxv?= =?us-ascii?Q?lJ9wL0hpS5l6MnJ4f0zNlqYdhgyztAs8OPIqtW4XJjU6kKcFu5HLy/AyG+9i?= =?us-ascii?Q?eopH/k+DfHfGi/oa+H+BUFLiiEPyyvs5bkY/JIqs3XGxlSux0LUF4m1A5S5X?= =?us-ascii?Q?RbKFKAZGUfAOMOG1EEUKah9SbeD7FH/Y3AdHVk+tvwm6ksCHxPDPaf95caYL?= =?us-ascii?Q?Gf8X6cdd/utDL3aAkLtr+yioGqY9pX4V/14/mCtkZdSwIzsLaAmiBMz5TcOq?= =?us-ascii?Q?5QpPUOQIw0wqVnZ+KiB2l3WkDqDdx+3g1JXvhWMiJrHewDyPK6dJbdZYztU6?= =?us-ascii?Q?fWlUPC+ddbBMbLe9sp+bQRQRprYsx33Pz5gguEqBm/QWAKEi3HaPVcGPwRQw?= =?us-ascii?Q?k7qlMu6nxolAPJWHDN8WqWgB6clDVLJLde5klwT1iG2qIzK6Ahn7ebueKTW+?= =?us-ascii?Q?GW8AR1TYJ8B/5ylcnnU7DAtpg+eFqgM5gg74Jz4qkTxRK4oMFpmstvOYHctb?= =?us-ascii?Q?z0BSUlFa2QwVCmRqjnhgzT4620pPOgVmDZuc5Kcdr83icWDPKIwpmg=3D=3D?= X-Forefront-PRVS: 03361FCC43 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(39410400002)(39400400002)(39850400002)(39840400002)(39450400003)(377454003)(24454002)(13464003)(377424004)(1076002)(3846002)(23726003)(66066001)(2906002)(33656002)(8676002)(81166006)(5009440100003)(47776003)(55016002)(33716001)(9686003)(6496005)(6246003)(189998001)(110136004)(38730400002)(76176999)(54356999)(50986999)(54906002)(42186005)(53936002)(478600001)(72206003)(93886004)(6666003)(2950100002)(42882006)(6916009)(5660300001)(4326008)(53546009)(25786009)(7736002)(305945005)(229853002)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0701MB1723; H:jerin; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0701MB1723; 23:OeV8f+DjCYoD/sGmoOsdIhYNiZWccEhJ4h12IvT?= =?us-ascii?Q?A+yl7aIW+ktJ96GeqSisiuZYoypwTy4oPqxl3c6JGlDm9YEbad3sjTT5yOIV?= =?us-ascii?Q?+vkfovxKh47/AMNWDgk4BM1xDrqaz7edpt2ZnhHFXrFdXdKDr2DesPigqodr?= =?us-ascii?Q?aPAq9xGsg3CP4JnIlkOvn57gENliDDWlqBBFYMKLutGhIt4XxPwzN7kY+jXE?= =?us-ascii?Q?XhQQqRiX8UZxw3FEyECZDrUEzDusHZyWAWh+G1rqfAIRUGWJ8ni8VDDm0VHi?= =?us-ascii?Q?TddpK3NHkSG42FCwak/9I1d+PCpYvAjYrqVrrDiHzBltcsggCtoGt4cGoftm?= =?us-ascii?Q?Ykxya2E5zhu5YLFaFQyePWVV9rYr29NZ9ILE+uadAH0r+wiw09xGpfO51D2j?= =?us-ascii?Q?Lv+57nEkO+ePY0nFPpWixbg+1rWwFFEXRTGdU/Ht8hWweMF/l5+IAsoWg82T?= =?us-ascii?Q?6WPIkNeJeUhaKm0T001+k2rTbd7efDEqDxO1uMoYj7RYbA+nhmsQkuoBw8ie?= =?us-ascii?Q?id73/g6zQgmh5lXdahIgSv/k5d5shMJJdpo4DOViRGoxxDYB7urEOTTV3viY?= =?us-ascii?Q?8UbUI/LLQXSAQA3H4riXs0CymjtXahRkux1nBqN9QZ08babM+8GpDiSm5VDT?= =?us-ascii?Q?Q0CgU6SSypKNQ9J6ILneLxb97vUYRTGe9SGU3rct2TB47PfurLMSAgl6estw?= =?us-ascii?Q?dMDCOi+z5LoK08aV1wZw9rM2OSek2VTV6x5XRlEToKmOmJR1QJAbZQ+rtSZk?= =?us-ascii?Q?t+aDfNouHV5mZNHuHcnBEmgJgZyCLa7klbXkrNC1KJvmdwVQVAuWuNkpob1b?= =?us-ascii?Q?irvnQeDCJfP12qIFvdT7MSGUn3Tvx2rmDq4iQIwIiU8rftNY1DaBQOSjWZbe?= =?us-ascii?Q?Nvt4fIB6/76fgm4miyi7a9dvV/OCZYXTBnSo2025VYPWPF0HM+E4zATwErME?= =?us-ascii?Q?+nrlGaNvR7+tL6R6vzElcGp1kwR/7oNnIgvIquHrJDegzE47idiQQlvuZA0k?= =?us-ascii?Q?Gnw/WyANfDFvVzB8ReC/0TZJUCWUjpYZ3UJn9SGdFBzV2m/90/Vhc6JAfQMu?= =?us-ascii?Q?XavcDVbICSy/MAFutxbwq1ouORMNXaIjrHi8VsAibzdyw9lS2f5+Fl9Qwl5e?= =?us-ascii?Q?h9UemcY2imbvhRXad1QXbpvwjCVJYHe0DZsqzDCJwTnnIevGDfPRtNfaxVmL?= =?us-ascii?Q?dOFw9xcD4oF1Sa/nX7pKjWZD8MRXd4kLSWXi/HMcWNNaKdPSQu3W/2krFxk4?= =?us-ascii?Q?+XMXdkwl26BM5EXqcx8E=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1723; 6:ePRf8IhPPwYLowgNhad1fdFp/uX0E708SDh8Fon8gVtIT+CRiSnDOWfst2kdZ+YdRQzgOAoaaUcrpLp8HA6oAVot3WFi3ygtGcQBSCLW2Zd9nERLs1wAHemb2qsa810QDoC+x5DJlHVIyNVnb4pRKtnM8Uzk3NlViU5C1G89As/Pa875u3GDdv+A18Ex636FJ6Jx3+BVW7s05q2sbffvK0RaD2q3cwVVzDkJ/aPHvySKYalKdbicOZGnr8/4EoOR1vOk04QCMPLlGtRhhwd4RggbVw2303KKV8l4tYKnwL1D7Ea76/TbxbyWuNyEOzF+NYHjFuCpXnl1TM5kgwW/4sRdrXFPPTRgF7wufCgK9wT3jvBzgs2mSl/ELZ/AXEJqoS9eqZFhtKZt/QplwvJ/BWbwS4Awbc2hoq8anUEiVjy1kVWZu1PB7c/LiQX0/B/Id+LTLHnqpKWqmwRZylEeUgvd2oIn5U/OJZY3cpSXu+sJ4dKtSvCdLqTmRUJwgXt+mXPDR4euGipcRxML7IYx1w== X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1723; 5:UYAoeAZcm9OqLQlOjYRsUp//cyIPZoBPJ0PmKL30A6NTnhdDx9qM5YHY3UQKR1/vtcM+0QKV3E7ato9g0HUHvDFUoU9nVWZMteZPnd1e7tDchcO93F6kn0cC+zMNt8tv1X9mLU4idIVPfIWPaMq/4S5KbnqgGgFgg4n3dmVFg3ShdH4GWjDi/oESlYryKxEGfNlSp8Yal6FWf+5IS8LYhmdSnG599MmtqMXut8Y3cHgENndztRe89hOyXG/FGPeDY86QMUj+6+51Ja7nkJowD37Lx4k4c+aC6tyvBzfKH5eAoVODxS/7Eqghkgpid6NCJf0RipvydbMUlOTePbKwiKKVLrQQP7POryhwQ7wpNIkcuv2UojhpA7s2DdB4C4mxlpqMCDMPyMCgcVfDcTOiWHX88h/n6AME6VLIQyhUyagiuyPZ0ZCIiGrpyKyeUUJZq2eN6lVRqtLlQctgrzrgZpt55SxTuglkpXwbT167A6b78Uy3MaWNwEfDgcD1xeQx; 24:zHwqItLHHbFokk3Bs1dnzyk66pFOR/lfSAlYsc7IMml8qTCGrwGtOUHQnOc/FmQ/W/Mv64YMYVZZwJv+bPrIiUWUevhWLV+FTFwmiQgqtjY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1723; 7:LGOH2S7jB/OtsB77gK185WcX1Shvxfq0Vf4BtcyDPbBJEt2KSwCPwA7lF5cFjYxH33zNH3yj0h8AYwZmX6m4OYnupBAz+TAljcTJy8HPqzgZ6QMDBZnBwDew2haVmiy/HBiSYPGsufYJ6j81gjDZ9EBiNr1qtzzu9RbnQWapsFT68MYMNU2qQt3NDzvtWtRWYeIF/RvBZ8eRxwL50/092FBX3a3ztxXDvGeAevYeiYNxGA3q2/rxog2NANYfCPuR2lVoKQzcnjywhcd6284qB2C2o3XYDvY8ZE0+kyfbf+4ZR4+VtiC1QYDaSAH7X8Z+CwzCjJl3lEwz6Zaaiwl4AA== X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2017 13:20:33.2618 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0701MB1723 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 13:20:40 -0000 -----Original Message----- > Date: Mon, 12 Jun 2017 12:51:26 +0000 > From: "Ananyev, Konstantin" > To: Jerin Jacob > CC: "Richardson, Bruce" , 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 1:42 PM > > To: Ananyev, Konstantin > > Cc: Richardson, Bruce ; 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: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. > > I understand that part, what I don't understand how not providing empty cache line > (for specific HW) will improve L1/L2 cache usage? > Suppose you do have an empty line for all cases, and HW doesn't fetch next cache line. > Then it should never occur into the cache hierarchy anyway: > You never read/write to it manually, HW doesn't speculatively fetch it. > correct? Yes. You are right. > Konstantin >