From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH v4 08/13] testpmd: rework csum forward engine Date: Thu, 27 Nov 2014 10:10:31 +0100 Message-ID: <5476EA87.4040807@6wind.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "jigsaw-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" To: "Ananyev, Konstantin" , "dev-VfR2kkLFssw@public.gmane.org" Return-path: In-Reply-To: <2601191342CEEE43887BDE71AB977258213BAA86-kPTMFJFq+rEu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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