From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-eopbgr710074.outbound.protection.outlook.com [40.107.71.74]) by dpdk.org (Postfix) with ESMTP id D83B029D1 for ; Thu, 2 Jun 2016 11:30:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oof5uVltM3NojYKHtQ0Zvz90wXprtil4p/DFvn+mQXI=; b=d3fZed1kN1Nq+CyR2VGWS54BP0qcNiCrnb4U6Lv0GjNW4G9BbhIkzEV/oDEK/MkWEKWi/aJ7So1u3vUaI7PGjPrHnRvqoDN7JJ2a/Td/bewLasoy5W3wrgnQaFSQpr6TnmIe4r8P+QvCY+/hrd9fIrWjViIRj4TkmIQ9O4q8RxM= Authentication-Results: linaro.org; dkim=none (message not signed) header.d=none;linaro.org; dmarc=none action=none header.from=caviumnetworks.com; Received: from localhost.localdomain (111.93.218.67) by BLUPR0701MB1714.namprd07.prod.outlook.com (10.163.85.140) with Microsoft SMTP Server (TLS) id 15.1.506.9; Thu, 2 Jun 2016 09:30:32 +0000 Date: Thu, 2 Jun 2016 15:00:08 +0530 From: Jerin Jacob To: Jianbo Liu CC: Olivier MATZ , Message-ID: <20160602093006.GA6794@localhost.localdomain> References: <1464663966-8122-1-git-send-email-jianbo.liu@linaro.org> <574DE5D6.2040001@6wind.com> <20160601060028.GA3823@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [111.93.218.67] X-ClientProxiedBy: MA1PR01CA0052.INDPRD01.PROD.OUTLOOK.COM (10.164.116.152) To BLUPR0701MB1714.namprd07.prod.outlook.com (10.163.85.140) X-MS-Office365-Filtering-Correlation-Id: b2193bed-e60e-4dd5-1686-08d38ac88c32 X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 2:wsu3JUq8Rk1qeADyH3jxUvBOw78tYWRBeTEO/SVTJSb43Edgsg9S+FC+W9n4ECj/0PuUKL+6f/rwcCu7In+lerGPBBSh2HmeGl0ATX/3U0iW/gQGWNcOBRO6Ab14F+9jJ4bRRiKyjGRlbl67Gk0NhH+O2R1vLI3qBqiiIx72h7DDr1LAal5kNs8qLgZQZi59; 3:gLxhhrCMRSIAeqG9JdyePRl74UFClATrVIgx6sGfM3LFYdmjkerx4WBI2NlGvWPJCUGfUkUnqSrEB9RVpFmL5xd5SVI3MD0PK5P8m0vb+EVCzaowOvGUmqL7kpk6CTGY; 25:JuJVP0jzj+MUgH+s7ezQveYSYL0ZD1eevEJBvZHZqbA2GebDWQFbzG4VhlBNoFxFsYJZbDL68y88ZW8PMTVmSQ9eA/uiEjLio+ftJDpF/f82tdPIMKqrHOB01+5u/SEWZFbF70m/wJj7AcgZRMXZQkH0VhW6H+ugoilGsSdirVWbO0QsJHyPtg0zdzKIUqVFx9//j8mvNULa08h+7Thq3/K6RKwN0q7HLywgf8SDvkvE5FByT+zxNk9Eqkk181KXlB5n1NOBCcxZQODGSmT5dN3aG4MM2nqXApLJBDVOjENCpSLNiujR0kn6ok9zQO42dxLLe/kRE/ANT0NayZ7BXxATda8MQVI2oqT9WrNBOhoO8f/lPA5VlVxGkWduFC+QCBOymhmrOGjmtMN6RcxKp8sV2UK8cKndpNs5ePMHFKg= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0701MB1714; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 20:Qb0RHyxDYbB1/kUZ/PEFtXjs1rrCqfVkKEH5IjzaCQ31qnev2gcF/o8LYiwaCkFNwjyXFoyVkPUU0WReZN33DLTskQPdMKQRr/njVABvjx63spt/uK8VxpqFzKc1ALcoPJ2v1UcYZkNLRW3g5USQseKYtYiG4pC67nvfzHwM9k02zluGHybQ/ECWP2uv5+fY3ng+xEkIHB8IiRsTT9ckaiVYaHnyaSs/oomm467u717e+DUomdBmY5MyRK2Q3Q6QR1aV/P5nKu6I3hWspuvy6yHQ6Uc+ADgWjjOPAyIEZqbcClqq4oJI3REU6grhN2+nodO0ZfZHgQ9krMIgjbooFeZfkf9mW7cdtu7RKuEjL+5QOGL306vnZqeUK9lsNOscwXP/UqdqMbzxnW57IoRFIg0hK3bF9bk1qDUgd4JvzRAgDDdSb8LUJavyBWoTbW1y4VIOvy40AWueCkIyzI+LjcAuyrF89Y56/zrKiiDVKuNIsVZjuUPQ/AJrbo9FCZ64dB5rH2mIfqL2Jp8OfJsd7aw11Zk10ur2CVfhMnxvqtXGXNbZrJO3U8XdmRfXwaIQPjZ4vjE4pYKVqCsksbnUChlxcp5Q01U6FbqH4peA3jE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BLUPR0701MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0701MB1714; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 4:YTM6VVWJmJDchgxfDv33C9yNwFdGBq1xG6WJiY3cJceTjfAcd39q9RxCjycll+UqKZBh0ZSQTagcE5KSajuWsXUmmyyWnr0VHbIjWf2UJlvgq5zc3Vpmo8Lg32jXxvUEf+iWjp4Ai1N2Rsh8/GowTaciMBybZbkBeU3tju7LfHzZOlvJFH4DXfBLpVQ2BdlROb6nmJdpuhcC97VdH8xuu/WzA7wri96hM7rYW7nbT5s8IPY6jNE7+rR5nS0OTvvP9hlXCb0GXVx22R1IaDO1uWJVeD7I1ewhk+mewkQEsslGCyE2SCbT06hVneCDffNwjK6g+80Cz8LwrzU83JDy8YkgRj4donUADD2OLWxQF9OWRV40ahdDHM3E2VUP4jc1 X-Forefront-PRVS: 0961DF5286 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6069001)(6009001)(377454003)(24454002)(4326007)(110136002)(5004730100002)(42186005)(47776003)(66066001)(97756001)(2906002)(5008740100001)(189998001)(50466002)(61506002)(33656002)(92566002)(9686002)(50986999)(586003)(2950100001)(54356999)(76176999)(93886004)(81166006)(1076002)(3846002)(77096005)(23726003)(83506001)(46406003)(5009440100003)(6116002)(4001350100001)(8676002)(19580405001)(19580395003)(7099028); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0701MB1714; H:localhost.localdomain; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0701MB1714; 23:VuiqpL+VuqA3ag3kVQCMjFhKGUl4Zzk7broR+wh?= =?us-ascii?Q?MhECtfP3bciN5gfsgqQvlKcV7CKxdYeAcEQ3QuQ8MSqUhWAVN6mCwRO/tgN/?= =?us-ascii?Q?080h8uTbVPhlww7ufV050fTUxwwcLTJkffzOa2GSlCV5zTrn3eJCq8TgSNB2?= =?us-ascii?Q?VT2h8HD9OYFqCjPfeBahDIOwto5akwmea8SaA3r2eRJoJ68bzk+WgOWVQQ3Y?= =?us-ascii?Q?lsoKU1H9cwEzin8Ik2OCTwT/jiD0xAGtv9lWsSo+lHSkbqak+p71yJCIRHSl?= =?us-ascii?Q?Kp82WGaMFguhIO1Z2uGl+wT6Y+j1vA2IvUwju4cwcT7zdclfm2hagQdR3t4r?= =?us-ascii?Q?FKZ60Z1NwA5d7Yi2K7rnUIuztv0lVZ73ZMpT2c7IizQLlUu27K09VECW4pIu?= =?us-ascii?Q?pbR7HvODbpLXO+Zh1lJq0WlkDj4NxVTWJGITUqqhVPyoLLVuaUMFnhMU3IUs?= =?us-ascii?Q?SypPhUYABJF6dV0dFevwREh8wCWhA4SziRtAyTr1B94P4VizyPmfoWVY9JvM?= =?us-ascii?Q?ydwQ73ZbMXJsbfALjTt1quEHDDjJZv9YHqE4gFChV/McnWClp8oByqsAzzwv?= =?us-ascii?Q?NE5PBREWVhvl+btNkmr0VTNJ3xBWpUkQwAWqhVxrKcmIF8jzyjAlCG+GU45J?= =?us-ascii?Q?k/KPVTFVe12wmFYLfVcKCjlejq56FLJeKQHx/R8Je8MV6cx6YgYRKbNwZ6Jx?= =?us-ascii?Q?46XBDhqiGszLh6HzbfXvZ80fB/2Pk0TYNVZ95bMS8ouB4/hbJ5EOJ4kKHwhA?= =?us-ascii?Q?bW41Tq+HF6wkR3PnhPSYNVuGZGK5QEzD3nq/qbfKDGbfBqW1tBGl3DGxIQml?= =?us-ascii?Q?Rkuox9E97tRv2xvnRC6P1eTXIA4FdkRK/ZExI6UbmFUkgnG/jEW450jtL24u?= =?us-ascii?Q?H8uvPO4EiaUS60l/Rz/4w3qYdRJ51zHO9TiKjqnrML7B85jiEmmEVFm0EoAe?= =?us-ascii?Q?EiXtcqg4g/YfHl6xlORYx9ze0togC5gYcEBpnfR1zzr9ShFDf9eXTcAwQ2pU?= =?us-ascii?Q?QgeQv/wycWLchPM1lI8l+BOYVEMxpz3vrEJe9lkTU803t94rh8Dv5mb8Vq/z?= =?us-ascii?Q?/iuFgPR5EL0S/I4kKbAY4vS0zMkkX?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 5:wMAQPwJglzlat/pdO+7//Vsgvl3gt3OWRjtn9+WW7cfkBkQWAnuFsYrGos5EbhuJQnbnj/1xjimmwpkcqX3D+CTs4ahWx2Z0VDdCiEiry96325URge2XvfS0pkvRms1l6giFOTQdty2A+Zyq3kwH+g==; 24:5oEjBW4ZX7GU4ghGgn6FyChCGrt3dmOI1Y6vkg2owl9FtfJh587V9UTWdpss/dOdyCVWNudJmlok0TGOljFUOVpKhwKAWf+TXKpA30SkP8Q=; 7:w9B0XfSuZI/Re0ADLTr3RAxpoxzNDf6DJxyF8ANx0qw5g9+jMJvM9fdFnplwIJiCxwtJ5g9FmwbAaJraWTT0/aZgfC/FVtuXxocKwotw9zNQAUpLJkVuiOlGnQ44oKIVAME2dMUXWdYbSGQinD2cSAX5p1m6PS1lOQfs4XGwsQ/ep4WbKpVv2WiQBC6DV7Vn SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2016 09:30:32.6275 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1714 Subject: Re: [dpdk-dev] [PATCH] mbuf: extend rte_mbuf_prefetch_part* to support more prefetching methods X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 09:30:36 -0000 On Thu, Jun 02, 2016 at 05:04:13PM +0800, Jianbo Liu wrote: > On 1 June 2016 at 14:00, Jerin Jacob wrote: > > On Wed, Jun 01, 2016 at 11:29:47AM +0800, Jianbo Liu wrote: > >> On 1 June 2016 at 03:28, Olivier MATZ wrote: > >> > Hi Jianbo, > >> > > >> > On 05/31/2016 05:06 AM, Jianbo Liu wrote: > >> >> Change the inline function to macro with parameters > >> >> > >> >> Signed-off-by: Jianbo Liu > >> >> > >> >> [...] > [...] > >> It's for performance consideration, and only on armv8a platform. > > > > Strictly it is not armv8 specific, IA also implemented this API with > > _MM_HINT_NTA hint. > > I mean this patch is only for ixgbe vector PMD on armv8 platform. > > > > > Do we really need non-temporal/transient version of prefetch for ixgbe? > > Strictly speaking, we don't have to since we don't know how APPs use > the mbuf header. Then IMO it makes sense to keep the same behavior as x86 ixgbe driver. Then on the upside, We may not need the new macros for part prefetching Jerin > But, is it high possibility that the second part is used only once or > short period because prefetching is done only when split_packet is not > NULL? > > > If so, for x86 also it makes sense to keep it? Right? > > > > The primary use case for transient version would be use with pipe line > > line mode where the same cpu wont consume the packet. > > > > /** > > * Prefetch a cache line into all cache levels (non-temporal/transient > > * version) > > * > > * The non-temporal prefetch is intended as a prefetch hint that > > * processor will > > * use the prefetched data only once or short period, unlike the > > * rte_prefetch0() function which imply that prefetched data to use > > * repeatedly. > > * > > * @param p > > * Address to prefetch > > */ > > static inline void rte_prefetch_non_temporal(const volatile void *p); > > > >> > >> > > >> > By the way, I did not try to apply the patch, but it looks > >> > it's on top of dpdk-next-net/rel_16_07, right? > >> > > >> Yes