From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 479527F25 for ; Fri, 7 Nov 2014 18:06:52 +0100 (CET) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XmnBr-0008F9-8O; Fri, 07 Nov 2014 18:19:19 +0100 Message-ID: <545CFE56.60605@6wind.com> Date: Fri, 07 Nov 2014 18:16:06 +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: Yong Wang , "Liu, Jijiang" References: <1414376006-31402-1-git-send-email-jijiang.liu@intel.com> <1414376006-31402-11-git-send-email-jijiang.liu@intel.com> <54588BF7.309@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D8510E@SHSMSX101.ccr.corp.intel.com>, <5459FBB2.1040408@6wind.com> <0c654d2c0d304b45a40af6ca38b70adf@EX13-MBX-026.vmware.com> In-Reply-To: <0c654d2c0d304b45a40af6ca38b70adf@EX13-MBX-026.vmware.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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: Fri, 07 Nov 2014 17:06:52 -0000 Hello Yong, On 11/07/2014 01:43 AM, Yong Wang wrote: >>> As to HW TX checksum offload, do you have special requirement for implementing TSO? > >> Yes. TSO implies TX TCP and IP checksum offload. > > Is this a general requirement or something specific to ixgbe/i40e? FWIW, > vmxnet3 device does not support tx IP checksum offload but doe support > TSO. In that case, we cannot leave IP checksum field as 0 (the correct > checksum needs to be filled in the header) before passing it the the NIC > when TSO is enabled. This is a good question because we need to define the proper API that will work on other PMDs in the future. Indeed, there is a hardware specificity in ixgbe: when TSO is enabled, the IP checksum flag must also be passed to the driver if it's IPv4. >>From 82599 datasheets (7.2.3.2.4 Advanced Transmit Data Descriptor): IXSM (bit 0) — Insert IP Checksum: This field indicates that IP checksum must be inserted. In IPv6 mode, it must be reset to 0b. If DCMD.TSE and TUCMD.IPV4 are set, IXSM must be set as well. If this bit is set, the packet should at least contain an IP header. If we allow the user to give the TSO flag without the IP checksum flag in mbuf flags, the ixgbe driver would have to set the IP checksum flag in hardware descriptors if the packet is IPv4. The driver would have to parse the IP header: this is not a problem as we already need it for TCP checksum. To summarize, I think we have 3 options when transmitting a packet to be segmented using TSO: - set IP checksum to 0 in the application: in this case, it would require additional work in virtual drivers if the peer expects to receive a packet with a valid IP checksum. But I'm wondering what is the need for calculating a checksum when transmitting on a virtual device (the peer receiving the packet knows that the packet is not corrupted as it comes from memory). Moreover, if the device advertise TSO, I assume it can also advertise IP checksum offload. - calculate the IP checksum in the application. It would take additional cycles although it may not be needed as the driver probably knows how to calculate it. - if the driver supports both TSO and IP checksum, the 2 flags MUST be given to the driver and the IP checksum must be set to 0 and the checksum cannot be calculated in software. If the driver only supports TSO, the checksum has to be calculated in software. Currently, I choosen the first solution, but I'm open to change the design. Maybe the 3rd one is also a good solution. By the way, we had the same kind of discussion with Konstantin [1] about what to do with the TCP checksum. My feeling is that setting it to the pseudo-header checksum is the best we can do: - linux does that - many hardware requires that (this is not the case for ixgbe, which need a pshdr checksum without the IP len) - it can be reused if received by a virtual device and sent to a physical device supporting TSO Best regards, Olivier [1] http://dpdk.org/ml/archives/dev/2014-May/002766.html