From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id D1EE0592E for ; Tue, 4 Nov 2014 09:09:47 +0100 (CET) Received: by mail-wg0-f52.google.com with SMTP id b13so12235294wgh.25 for ; Tue, 04 Nov 2014 00:19:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1zHyF2dXwkH5etK5Uc0XDkHDMB7f7Ti7gVlGsmGo4p8=; b=ai2N+ctfyOAtnL/HkDvkng1puUmPJAKWXmb0XWPzq++qYVJOVRNetgnQg2lhYRLX9G 6QNFUw8s9kIrCF5uU2D6eaorO3cXNCw+vs4FOZ6HGPRb9QiP03g6ZDMDBd1CllUiYw1g uEAkdHavQEr7H4zDvBfXrVsx++ODx9nil/ZeBJhCeGPHL8LyHMJ8VoKyvMWyP6FOBOQb bomImVurQ7s7UPkX3qvvnLorjk9HHmkyRCShQsAmhgHZb1wjDxGexa01C49b3YGvMAcs bPls2dJl80PMY/xrGxncZLgw7waN2ROYSQck30T2sJf+oyOOhpA1M5mIhOdV2kh3nxXI 7b9g== X-Gm-Message-State: ALoCoQmKnR5reh+dDNXQFQUVfZfdzl2fkxjUxSya9NvY26owJO+gjxzwOrymPI83M3oTgdm/gz9G X-Received: by 10.180.91.227 with SMTP id ch3mr12692334wib.17.1415089145432; Tue, 04 Nov 2014 00:19:05 -0800 (PST) Received: from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id fr6sm185448wic.1.2014.11.04.00.19.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Nov 2014 00:19:04 -0800 (PST) Message-ID: <54588BF7.309@6wind.com> Date: Tue, 04 Nov 2014 09:19:03 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Jijiang Liu References: <1414376006-31402-1-git-send-email-jijiang.liu@intel.com> <1414376006-31402-11-git-send-email-jijiang.liu@intel.com> In-Reply-To: <1414376006-31402-11-git-send-email-jijiang.liu@intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum offload 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: Tue, 04 Nov 2014 08:09:47 -0000 Hello Jijiang, On 10/27/2014 03:13 AM, Jijiang Liu wrote: > Add test cases in testpmd to test VxLAN Tx Checksum offload, which include > - IPv4 and IPv6 packet > - outer L3, inner L3 and L4 checksum offload for Tx side. > > Signed-off-by: Jijiang Liu I'm trying to port the test of TSO in csum_only.c which was originally part of this patch [1]. Meanwhile, the source was modified by the patch provided by the email I'm replying to (also available at [2]), and I would like to understand what is the purpose of it. First, the code checks if the mbuf has the flag PKT_RX_TUNNEL_IPV4_HDR. What is the meaning of this flag? It was added by [3], but there is no description in comments or in the commit log explaining in which case this flag is set by the driver. The name supposes that this flag is set when the received packet is an IPv4 tunnel, but the commit log talks about vxlan. Then, if this flag was present, the code assumes it's a vxlan packet. If one of inner checksum is specified by the user in cmdline, the flag PKT_TX_VXLAN_CKSUM is added to the mbuf. This flag definition was added by [4] (at the wrong place, I'll fix it in my patchset). What is the meaning of this flag? Is it enough to checksum outer L3, inner L3, and inner L4 as specified in commit log? If yes, why are the other flags PKT_TX_IPV4_CSUM, PKT_TX_UDP_CKSUM, (...) added in the mbuf later? In my comprehension, these flags are needed in addition to PKT_TX_VXLAN_CKSUM to do the checksum of the inner headers. In general, I need to understand how to use all the new offloading stuff. In [5], new fields were added in the mbuf structure (inner_l3_len and inner_l2_len). I'm not sure I understand which fields have to be filled. Below is my understanding, can you please check that it is correct? A- To send a Ether/IP/TCP packet and process IP and TCP TX checksum in the NIC: - set l2_len = 14, l3_len = 20, ol_flags = PKT_TX_IP_CKSUM | PKT_TX_TCP_CKSUM, write all checksums to 0 in the packet B- To send a Ether/IP/UDP/vxlan/Ether/IP/TCP packet and process inner IP and inner TCP TX checksum in the NIC: - set l2_len = 14+20+8+8+14, l3_len = 20, ol_flags = PKT_TX_IP_CKSUM | PKT_TX_TCP_CKSUM, write all checksums to 0 in the packet C- To send a Ether/IP/UDP/vxlan/Ether/IP/TCP packet and process outer IP and UDP, plus inner IP and inner TCP TX checksum in the NIC: - set l2_len = 14, l3_len = 20, inner_l2_len = 14, inner_l3_len = 20, ol_flags = PKT_TX_IP_CKSUM | PKT_TX_TCP_CKSUM | PKT_TX_VXLAN_CKSUM, write all checksums to 0 in the packet D- To send a Ether/IP/UDP/vxlan/Ether/IP/TCP packet and process outer IP and UDP TX checksum in the NIC: - set l2_len = 14, l3_len = 20, ol_flags = PKT_TX_IP_CKSUM | PKT_TX_UDP_CKSUM, write all checksums to 0 in the packet First, can you confirm this? I think it is very important to document it, as this is a public API that can be used by DPDK users. To validate my modifications, I will try to reproduce the test plan described in [6]. The test report contains useful information but I'm not sure to understand the following: Enable outer IP,UDP,TCP,SCTP and inner IP,UDP checksum offload when inner L4 protocal is UDP. testpmd>tx_checksum set 0 0xf3 Enable outer IP,UDP,TCP,SCTP and inner IP,TCP,SCTP checksum offload when inner L4 protocal is TCP or SCTP. testpmd>tx_checksum set 0 0xfd Can you give details about the signification of the bits used in the tx_checksum command? For instance, there is only one flag to enable tx checksum in the mbuf, so I don't understand how it's possible to do 0x44 = (inner tcp + outer tcp). Today, there are hard-coded values for flags: 4 bits (0-3) for legacy checksums, 4 bits for inner checksums (4-7), and one bit (bit 11?!) for vlan header. These bits are checked without defines at several places in the code. Moreover, there are some places in code where the testpmd port flags and the mbuf flags are mixed up. Example in macswap.c : mb->ol_flags = txp->tx_ol_flags; I suggest to remove all hardcoded values except in cmd_tx_cksum_set_parsed() and replace them by the flags definitions from rte_mbuf.h. As a result, the new possible arguments of cmd_tx_cksum_set_parsed() will map the mbuf flags: - a flag to enable ip tx cksum - a flag to enable udp tx cksum - a flag to enable tcp tx cksum - a flag to enable sctp tx cksum - a flag to enable vxlan tx cksum If vxlan tx cksum is set, therefore the other considered checksum will concern the inner headers. Do you think it matches your needs? I think that the csum_only forward engine is now a bit complicated. As it's an example that shows how to configure the tx checksum, I think its behavior should be described somewhere, maybe in a comment in the file. By the way, I was looking at the mbuf structure, and I see that a new packet_type field was added. There is no explanation about what this field should contain and how we shall use it (in commit log or in comments). Can you please explain it? To conclude, I'd like to propose a merge of the TSO series but I'm currently blocked by these questions. Please, could you help me to progress on this? Regards, Olivier [1] http://dpdk.org/ml/archives/dev/2014-May/002549.html [2] http://dpdk.org/ml/archives/dev/2014-October/007156.html [3] http://dpdk.org/browse/dpdk/commit/lib/librte_mbuf/rte_mbuf.h?id=15dbb63ef9e9f108e7dcd837b88234f27a1ec258 [4] http://dpdk.org/browse/dpdk/commit/lib/librte_mbuf/rte_mbuf.h?id=77b8301733c3cd946648ca4a1375e3db0a952216 [5] http://dpdk.org/browse/dpdk/commit/lib/librte_mbuf/rte_mbuf.h?id=73b7d59cf4f6faf5ccd83ce706473e75c6fb8c3b [6] http://dpdk.org/ml/archives/dev/2014-October/007157.html