From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by dpdk.org (Postfix) with ESMTP id C5C14282 for ; Thu, 27 Nov 2014 10:10:32 +0100 (CET) Received: by mail-wi0-f178.google.com with SMTP id hi2so7580674wib.11 for ; Thu, 27 Nov 2014 01:10:32 -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=oJsGn8YnVTsQf4N4lX4BeuBmaTG5xApcu3Sr2u8/3bU=; b=NFo/Qxp4NDRgF6tB7a8xu2S5jTbVqXitOvhCOg3ML0wodTt8S5knIfGww2FzKW63ER 31P5AirN7oRv3ulonpixxcZcKVGs0WFEO5x3Fij90KE/WdXtHsXNGsRYmehRSVZQF5pW CyYPZCgnJZNSzDkbSv17I3ses8b3y07qVcLt4oCravfGKXG0sBzecVVgN/UE2WnS0t2e IolC/bn6+za5QlHWqRPVBFo9IUa6tJRZqV6E4QvHymbzJ20vR43nk0j0J0tBWNVP+JMI hb7JmuiNDHKDlFDcGWGSwqbzUUhpRRXcg6mchUS8Mjd8YPTbKfP7aCdbleuckVrmj/Iw zUJQ== X-Gm-Message-State: ALoCoQmk43Hbkp1rvRVhGRbQ2hFF3cK0ZbZpLTR6c2FzSY44PZQCwj8HNV1a2uPUrH58vtCbtHOT X-Received: by 10.180.95.74 with SMTP id di10mr50079573wib.54.1417079432603; Thu, 27 Nov 2014 01:10:32 -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 ud1sm9816301wjc.7.2014.11.27.01.10.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Nov 2014 01:10:32 -0800 (PST) Message-ID: <5476EA87.4040807@6wind.com> Date: Thu, 27 Nov 2014 10:10:31 +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: "Ananyev, Konstantin" , "dev@dpdk.org" References: <1416524335-22753-1-git-send-email-olivier.matz@6wind.com> <1417014295-29064-1-git-send-email-olivier.matz@6wind.com> <1417014295-29064-9-git-send-email-olivier.matz@6wind.com> <2601191342CEEE43887BDE71AB977258213BAA86@IRSMSX105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258213BAA86@IRSMSX105.ger.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "jigsaw@gmail.com" Subject: Re: [dpdk-dev] [PATCH v4 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: Thu, 27 Nov 2014 09:10:33 -0000 Hi Konstantin, On 11/26/2014 09:02 PM, Ananyev, Konstantin wrote: >> +/* if possible, calculate the checksum of a packet in hw or sw, >> + * depending on the testpmd command line configuration */ >> +static uint64_t >> +process_inner_cksums(void *l3_hdr, uint16_t ethertype, uint16_t l3_len, >> + uint8_t l4_proto, uint16_t testpmd_ol_flags) >> +{ >> + struct ipv4_hdr *ipv4_hdr = l3_hdr; >> + struct udp_hdr *udp_hdr; >> + struct tcp_hdr *tcp_hdr; >> + struct sctp_hdr *sctp_hdr; >> + uint64_t ol_flags = 0; >> + >> + if (ethertype == _htons(ETHER_TYPE_IPv4)) { >> + ipv4_hdr = l3_hdr; >> + ipv4_hdr->hdr_checksum = 0; >> + >> + if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_IP_CKSUM) >> + ol_flags |= PKT_TX_IP_CKSUM; >> + else >> + ipv4_hdr->hdr_checksum = get_ipv4_cksum(ipv4_hdr); >> + >> + ol_flags |= PKT_TX_IPV4; > > Flags PKT_TX_IP_CKSUM, PKT_TX_IPV4, PKT_TX_IPV6 are all mutually exclusive. > So it should be, I think: > > if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_IP_CKSUM) { > ol_flags |= PKT_TX_IP_CKSUM; > } else { > ipv4_hdr->hdr_checksum = get_ipv4_cksum(ipv4_hdr); > ol_flags |= PKT_TX_IPV4; > } It seems normal that PKT_TX_IPV4 are PKT_TX_IPV6 exclusive, but do you mean that PKT_TX_IP_CKSUM and PKT_TX_IPV4 are exclusive too? It looks strange to me. My understanding of the meaning of the flags is: - PKT_TX_IP_CKSUM: tell the NIC to compute IP cksum - PKT_TX_IPV4: tell the NIC it's an IPv4 packet. Required for L4 checksum offload or TSO. - PKT_TX_IPV6: tell the NIC it's an IPv6 packet. Required for L4 checksum offload or TSO. If it's a i40e driver requirement, don't you think it's better to change the driver? >> +/* 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); >> + } >> + >> + udp_hdr = (struct udp_hdr *)((char *)outer_l3_hdr + outer_l3_len); >> + /* do not recalculate udp cksum if it was 0 */ >> + if (udp_hdr->dgram_cksum != 0) { >> + udp_hdr->dgram_cksum = 0; >> + if ((testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM) == 0) { > > In fact, FVL is not able to do HW caclualtion for outer L4, only outer IPV4 cksum is supported. > So no need for: > if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_UDP_CKSUM) { > above. > And yes, if user will select to calculate inner checksums by HW - outer UDP checksum might be invalid anyway. I may have misunderstood how vxlan works, so I agree this code is probably wrong. However, I don't find the line you are quoting in the function above. I'll check how Jijiang fixed the issue. Regards, Olivier