From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id 6C5ED2BD4 for ; Thu, 21 Apr 2016 11:54:35 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id n3so123842433wmn.0 for ; Thu, 21 Apr 2016 02:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=H8jBlpw8kst2vb07o3j94CWNruYjJnAmoDYRGZhmvfs=; b=KUYPp1R7uCSwg0thcqcN56S/9B/Q2UyoOB4WLHh0/Vd+SELZqih+J7c7kLj0dxq5rP e2zJi+PYxpkldGp3p0UBqgoPeLMzCxb1KCUIGND2GVZh4uwvSWP1RKJTCb+CEVhBNvUd i07UAZ4AyqVeMYx0cV5eOWueCNsZU62brzg8D1lyyq/KtCpLa0+Wbm1O6TQtoQ2Cnbs8 2LRjB4UBCDCnhxpJXuS8vbb5aPH+hUuiz6ChUW5X87m1QW/9B6Iif+K9gSR1yyOiTJBM 3ivcEWWDS957EyLpOmop5e6GQJ2IxdyK30o3jAS1jxuT+jJw6+4Ky4d0AsnJwVmnLQ0F O5Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding; bh=H8jBlpw8kst2vb07o3j94CWNruYjJnAmoDYRGZhmvfs=; b=l8UPIZDo/P5KkMnFBOP2+sBxK7nds+PyAG16fMHjiGD95uRlARwT1MQYDorMBtdI+R tQBe0I9yLVRqWShTkgDSjjuIHbarXV82JwhiH4kUZ/eY3TyhSPkiwDsMw7H7L82w3om3 Dz7Fr3jArvbpqM5B0oloLEaivLJbl+wk2Ke+UuXibNeFAWVX+VZ4owLylq25vtDI2DUS JNbA2eBSQUWwJkxypAprvG0/j2nPllGZXYo9A097UbaWjYDMh4slD1h4i4chMZggpy+g XIYBKftni799t3NLKiNQqnzH3hcErrmzeUTVv4stTiJjf8QGTOT7+QdTOGXAoaZyMfMc Z2Og== X-Gm-Message-State: AOPr4FUXh+W1UR2W7HRJwIKSPxFFQWCTqDeYGcWQSNdmBawPcKYJWANkqepwLTacyaDlaM+5 X-Received: by 10.194.2.130 with SMTP id 2mr13088039wju.77.1461232475243; Thu, 21 Apr 2016 02:54:35 -0700 (PDT) Received: from xps13.localnet (APoitiers-658-1-12-89.w86-213.abo.wanadoo.fr. [86.213.195.89]) by smtp.gmail.com with ESMTPSA id c4sm1975613wjm.24.2016.04.21.02.54.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Apr 2016 02:54:34 -0700 (PDT) From: Thomas Monjalon To: Zhihong Wang Cc: dev@dpdk.org, Pablo de Lara Date: Thu, 21 Apr 2016 11:54:12 +0200 Message-ID: <1946900.ocWSxO32dE@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1461192195-104070-1-git-send-email-zhihong.wang@intel.com> References: <1461192195-104070-1-git-send-email-zhihong.wang@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC PATCH 0/2] performance utility in testpmd 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, 21 Apr 2016 09:54:35 -0000 2016-04-20 18:43, Zhihong Wang: > This RFC patch proposes a general purpose forwarding engine in testpmd > namely "portfwd", to enable performance analysis and tuning for poll mode > drivers in vSwitching scenarios. > > > Problem statement > ----------------- > > vSwitching is more I/O bound in a lot of cases since there are a lot of > LLC/cross-core memory accesses. > > In order to reveal memory/cache behavior in real usage scenarios and enable > efficient performance analysis and tuning for vSwitching, DPDK needs a > sample application that supports traffic flow close to real deployment, > e.g. multi-tenancy, service chaining. > > There is a vhost sample application currently to enable simple vSwitching > scenarios, it comes with several limitations: > > 1) Traffic flow is too simple and not flexible > > 2) Switching based on MAC/VLAN only > > 3) Not enough performance metrics > > > Proposed solution > ----------------- > > The testpmd sample application is a good choice, it's a powerful poll mode > driver management framework hosts various forwarding engine. Not sure it is a good choice. The goal of testpmd is to test every PMD features. How far can we go in adding some stack processing while keeping it easily maintainable? > Now with the vhost pmd feature, it can also handle vhost devices, only a > new forwarding engine is needed to make use of it. Why a new forwarding engine is needed for vhost? > portfwd is implemented to this end. > > Features of portfwd: > > 1) Build up traffic from simple rx/tx to complex scenarios easily > > 2) Rich performance statistics for all ports Have you checked CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES and CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS? > 3) Core affinity manipulation > > 4) Commands for run time configuration > > Notice that portfwd has fair performance, but it's not for getting the > "maximum" numbers: > > 1) It buffers packets for burst send efficiency analysis, which increase > latency > > 2) It touches the packet header and collect performance statistics which > adds overheads > > These "extra" overheads are actually what happens in real applications. [...] > Implementation details > ---------------------- > > To enable flexible traffic flow setup, each port has 2 ways to forward > packets in portfwd: Should not it be 2 forward engines? Please first describe the existing engines to help making a decision. > 1) Forward based on dst ip [...] > 2) Forward to a fixed port [...]