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 99CA22A9 for ; Mon, 17 Nov 2014 13:50:09 +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 1XqLxg-0000pz-CP; Mon, 17 Nov 2014 14:03:29 +0100 Message-ID: <5469F156.2050806@6wind.com> Date: Mon, 17 Nov 2014 14:00: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: "Liu, Jijiang" References: <1415635166-1364-1-git-send-email-olivier.matz@6wind.com> <1415984609-2484-1-git-send-email-olivier.matz@6wind.com> <1415984609-2484-9-git-send-email-olivier.matz@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9BB44@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9BB44@SHSMSX101.ccr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" , "jigsaw@gmail.com" Subject: Re: [dpdk-dev] [PATCH v2 08/13] testpmd: rework csum forward engine 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: Mon, 17 Nov 2014 12:50:09 -0000 Hi Jijiang, On 11/17/2014 09:11 AM, Liu, Jijiang wrote: >> +/* Calculate the checksum of outer header (only vxlan is supported, >> + * meaning IP + UDP). The caller already checked that it's a vxlan >> + * packet */ >> +static uint64_t >> +process_outer_cksums(void *outer_l3_hdr, uint16_t outer_ethertype, >> + uint16_t outer_l3_len, uint16_t testpmd_ol_flags) { >> + struct ipv4_hdr *ipv4_hdr = outer_l3_hdr; >> + struct ipv6_hdr *ipv6_hdr = outer_l3_hdr; >> + struct udp_hdr *udp_hdr; >> + uint64_t ol_flags = 0; >> + >> + if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM) >> + ol_flags |= PKT_TX_VXLAN_CKSUM; >> + >> + if (outer_ethertype == _htons(ETHER_TYPE_IPv4)) { >> + ipv4_hdr->hdr_checksum = 0; >> + >> + if ((testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM) >> == 0) >> + ipv4_hdr->hdr_checksum = get_ipv4_cksum(ipv4_hdr); >> + } > > As I mentioned, we should use TESTPMD_TX_OFFLOAD_IP_CKSUM instead of using TESTPMD_TX_OFFLOAD_VXLAN_CKSUM flag to check if we need to set outer IP checksum offload. > In other words, even if VXLAN packet, outer IP TX checksum offload is also needed if TESTPMD_TX_OFFLOAD_IP_CKSUM is set. The csum forward engine works as follow after the rework. I can add some more comments in the patch or testpmd help to describe it more clearly. Receive a burst of packets, and for each packet: - parse packet, and try to recognize a supported packet type (1) - if it's not a supported packet type, don't touch the packet, else: - modify the IPs in inner headers and in outer headers if any - reprocess the checksum of all supported layers. This is done in SW or HW, depending on testpmd command line configuration - if TSO is enabled in testpmd command line, also flag the mbuf for TCP segmentation offload (this implies HW TCP checksum) Then transmit packets on the output port. (1) Supported packets are: Ether / (vlan) / IP|IP6 / UDP|TCP|SCTP . Ether / (vlan) / outer IP|IP6 / outer UDP / VxLAN / Ether / IP|IP6 / UDP|TCP|SCTP The testpmd command line for csum takes the following arguments: tx_cksum set (ip|udp|tcp|sctp|vxlan) (hw|sw) (port_id) - "ip|udp|tcp|sctp" always concern the inner layer - "vxlan" concerns the outer IP and UDP layer (if packet is recognized as a vxlan packet) Hope it's enough precisely described to be able to predict the output of testpmd without reading the code or the i40e datasheets. This was not so clear before. So, following this description, there is not reason to check the TESTPMD_TX_OFFLOAD_IP_CKSUM when scheduling the hardware VxLAN checksum. One thing may be wrong however, it's the mbuf flags set in the packet. But we cannot say it's wrong today because the API is not documented. But the VXLAN feature is not enough documented to be sure it's wrong. Regards, Olivier