From mboxrd@z Thu Jan 1 00:00:00 1970 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) Message-ID: <555138C7.5010002@net.in.tum.de> Date: Tue, 12 May 2015 01:18:31 +0200 From: Paul Emmerich User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dev@dpdk.org References: <554FF482.9080103@net.in.tum.de> <55512DE5.7010800@net.in.tum.de> In-Reply-To: <55512DE5.7010800@net.in.tum.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] TX performance regression caused by the mbuf cachline split 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: Mon, 11 May 2015 23:18:37 -0000 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