From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Emmerich Subject: Re: TX performance regression caused by the mbuf cachline split Date: Tue, 12 May 2015 01:18:31 +0200 Message-ID: <555138C7.5010002@net.in.tum.de> References: <554FF482.9080103@net.in.tum.de> <55512DE5.7010800@net.in.tum.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To: dev@dpdk.org Return-path: Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by dpdk.org (Postfix) with ESMTP id 65051376E for ; Tue, 12 May 2015 01:18:37 +0200 (CEST) Received: from Charizard-WiFi.fritz.box (p5DCD6AA3.dip0.t-ipconnect.de [93.205.106.163]) by mail.net.in.tum.de (Postfix) with ESMTPSA id BE33E1944B46 for ; Tue, 12 May 2015 01:18:31 +0200 (CEST) In-Reply-To: <55512DE5.7010800@net.in.tum.de> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Found a really simple solution that almost restores the original performance: just add a prefetch on alloc. For some reason, I assumed that this was already done since the troublesome commit I investigated mentioned something about prefetching... I guess the commit referred to the hardware prefetcher in the CPU. Adding an explicit prefetch command in the mbuf alloc function gives a throughput of 12.7/10.35 Mpps in my benchmark with the simple/full-featured tx path. DPDK 1.7.1 was at 14.1/10.7 Mpps. I guess I can live with that, since I'm primarily interested in the full-featured path and the drop from 10.7 to ~10.4 was due to another change. Patch: https://github.com/dpdk-org/dpdk/pull/2 I also sent an email to the mailing list. I also think that the rx-path could also benefit from prefetching somewhere. Paul