From patchwork Wed Aug 8 15:39:26 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Lam, Tiago" X-Patchwork-Id: 955163 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=openvswitch.org (client-ip=140.211.169.12; helo=mail.linuxfoundation.org; envelope-from=ovs-dev-bounces@openvswitch.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=intel.com Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41lwYR2nNzz9s0n for ; Thu, 9 Aug 2018 01:39:38 +1000 (AEST) Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id B9E04CDA; Wed, 8 Aug 2018 15:39:35 +0000 (UTC) X-Original-To: ovs-dev@openvswitch.org Delivered-To: ovs-dev@mail.linuxfoundation.org Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B391C8BF for ; Wed, 8 Aug 2018 15:39:34 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 46C46F1 for ; Wed, 8 Aug 2018 15:39:34 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Aug 2018 08:39:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,458,1531810800"; d="scan'208";a="80000925" Received: from silpixa00399125.ir.intel.com ([10.237.223.34]) by orsmga001.jf.intel.com with ESMTP; 08 Aug 2018 08:39:32 -0700 From: Tiago Lam To: ovs-dev@openvswitch.org Date: Wed, 8 Aug 2018 16:39:26 +0100 Message-Id: <1533742768-204340-1-git-send-email-tiago.lam@intel.com> X-Mailer: git-send-email 2.7.4 X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [ovs-dev] [RFC 0/2] dpdk: Add support for TSO X-BeenThere: ovs-dev@openvswitch.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: ovs-dev-bounces@openvswitch.org Errors-To: ovs-dev-bounces@openvswitch.org Enabling TSO offload allows a host stack to delegate the segmentation of oversized TCP packets to the underlying physical NIC, if supported. In the case of a VM this means that the segmentation of the packets is not performed by the guest kernel, but by the host NIC itself. In turn, since the TSO calculations and checksums are being performed in hardware, this alleviates the CPU load on the host system. In inter VM communication this might account to significant savings, and higher throughput, even more so if the VMs are running on the same host. Thus, although inter VM communication is already possible as is, there's a sacrifice in terms of CPU, which may affect the overall throughput. This series proposes to add support for TSO in OvS-DPDK, by making use of the TSO offloading feature already supported by DPDK vhost backend, having the following scenarios in mind: - Inter VM communication on the same host; - Inter VM communication on different hosts; - The same two use cases above, but on a VLAN network. The work is based on [1]; It has been rebased to run on top of the multi-segment mbufs work (v7) [2] and re-worked to use the new Tx offload API as per [3]. [1] https://patchwork.ozlabs.org/patch/749564/ [2] https://mail.openvswitch.org/pipermail/ovs-dev/2018-July/350081.html [3] http://dpdk.readthedocs.io/en/v17.11/rel_notes/deprecation.html Considerations: - This series depends on the multi-segment mbuf series (v7) and can't be applied on master as is; - Right now TSO is enabled by default when using multi-segment mbufs, or otherwise TSO is disabled and can't be set on its own. I'm open to opinions on this, though. My main idea to stick TSO behind multi-segment mbufs is: - The performance enhancements enabled by DPDK PMDs, such as vectorization, that are disabled when using multi-segment mbufs are also disabled when using some of the offload features; - By enabling the multi-segment mbuf flag, the packets have a default size of 2048B. This might be higher if not using multi-segments mbufs, since the size of the packet will be ajusted to the MTU (such as 9000B). This might lead to a higher waste of memory when appending mbufs to each other as we will be increamenting larger ammounts. - There's some initial documentation on patch 1/2 (which came form [1]), but needs improving. Tiago Lam (2): netdev-dpdk: Consider packets marked for TSO. netdev-dpdk: Enable TSO when using multi-seg mbufs Documentation/topics/dpdk/phy.rst | 64 ++++++++++++++ lib/dp-packet.c | 5 +- lib/netdev-dpdk.c | 172 ++++++++++++++++++++++++++++++-------- 3 files changed, 204 insertions(+), 37 deletions(-)