From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <emmericp@net.in.tum.de>
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 2D7DFC546
 for <dev@dpdk.org>; Tue, 28 Apr 2015 12:56:27 +0200 (CEST)
Received: from charmander.net.in.tum.de (charmander.net.in.tum.de
 [131.159.20.23])
 by mail.net.in.tum.de (Postfix) with ESMTPSA id 7A952188DBA7;
 Tue, 28 Apr 2015 12:56:26 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Paul Emmerich <emmericp@net.in.tum.de>
In-Reply-To: <0B4E9314-9F6A-4AE6-8B1F-B41F9A5264B1@mhcomputing.net>
Date: Tue, 28 Apr 2015 12:56:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <822BEC44-6C61-467A-9211-010EB553682D@net.in.tum.de>
References: <6DC6DE50-F94F-419C-98DF-3AD8DCD4F69D@net.in.tum.de>
 <CALgsdbciDyJLm8Rp9GNbDb6sN=eCcFEVkWsSw95fvG32mYfqBg@mail.gmail.com>
 <E115CCD9D858EF4F90C690B0DCB4D89727297ADB@IRSMSX108.ger.corp.intel.com>
 <23D2CA18-1875-4182-8DEE-9F6393011D2C@net.in.tum.de>
 <0B4E9314-9F6A-4AE6-8B1F-B41F9A5264B1@mhcomputing.net>
To: Matthew Hall <mhall@mhcomputing.net>
X-Mailer: Apple Mail (2.1878.6)
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Performance regression in DPDK 1.8/2.0
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Apr 2015 10:56:27 -0000

Hi,

Matthew Hall <mhall@mhcomputing.net>:
> Not sure if it's relevant or not, but there was another mail claiming =
PCIe MSI-X wasn't necessarily working in DPDK 2.x. Not sure if that =
could be causing slowdowns when there are drastic volumes of 64-byte =
packets causing a lot of PCI activity.

Interrupts should not be relevant here.


> Also, you are mentioning some specific patches were involved... so I =
have to ask if anybody tried git bisect yet or not. Maybe easier than =
trying to guess at the answer.

I have not yet tried to bisect it, but that=92s the next step
on my todo list*. The mbuf patch was just an educated=20
guess to start a discussion.

I hoped that I was just doing something obvious wrong,
and/or that someone could point me to performance
regression tests that were executed to proof that the mbuf
patch does not affect performance.

However, there don=92t seem to be any 'official=91 performance
regression tests, are there?


Paul

* I probably won=92t be able to it until next week, though as
I have to to finish the paper about my packet generator=