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 EFB401B3EA; Tue, 23 Oct 2018 11:02:04 +0200 (CEST) Received: from rsa59-2-82-233-193-189.fbx.proxad.net ([82.233.193.189] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gEsar-0003fi-KN; Tue, 23 Oct 2018 11:03:19 +0200 Received: by droids-corp.org (sSMTP sendmail emulation); Tue, 23 Oct 2018 11:01:58 +0200 Date: Tue, 23 Oct 2018 11:01:58 +0200 From: Olivier Matz To: Ferruh Yigit Cc: Shyam Shrivastav , lidejun1@huawei.com, users , dev@dpdk.org, lichunhe@huawei.com, zhangxufeng4@huawei.com Message-ID: <20181023090158.z5w3gtvdzax247w6@platinum> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-users] [dpdk-dev] IPV4/IPV6 TCP/UDP Pseudo Header Checksum APIs X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 09:02:05 -0000 Hi, You are right, the current code does not take IP or IPv6 options in account. I think this should be considered as a bug. The fix for IPv4 is not complicated, I did a quick draft here: http://git.droids-corp.org/?p=dpdk.git;a=commitdiff;h=96a6978ef6814e1450e1bd65fbce91c3d85b3121 For IPv6, it is more complex than expected: https://tools.ietf.org/html/rfc2460.html#section-8.1 - we need to skip extension headers - we need to parse routing headers and use the proper destination address in the pseudo header checksum This makes me think that the API is not adequate. Asking the user to provide the headers in a contiguous memory without specifying the length is quite dangerous, especially if the header comes from outside, as it can trigger out of bound accesses. I wonder if we shouldn't switch to a mbuf based API instead, and deprecate the old one. Thoughts? Olivier On Mon, Oct 22, 2018 at 09:03:14AM +0100, Ferruh Yigit wrote: > On 10/20/2018 7:30 AM, Shyam Shrivastav wrote: > > Yes you are right, I misread, following code (ipv4 case) assumes no ip > > options while calculating pseudo hdr length field > > > > psd_hdr.len = rte_cpu_to_be_16( > > (uint16_t)(rte_be_to_cpu_16(ipv4_hdr->total_length) > > - sizeof(struct ipv4_hdr))); > > > > should be > > > > psd_hdr.len = rte_cpu_to_be_16( > > (uint16_t)(rte_be_to_cpu_16(ipv4_hdr->total_length) > > - (ipv4_hdr->version_ihl & 0x0f)*4))); > > cc'ed maintainer of the that part, Olivier. > > > > > On Sat, Oct 20, 2018 at 11:44 AM lidejun wrote: > > > >> I mean DPDK APIs do not exclude ipv4 options or ipv6 extension headers, it > >> is bug? > >> > >> > >> > >> *发件人:* Shyam Shrivastav [mailto:shrivastav.shyam@gmail.com] > >> *发送时间:* 2018年10月20日 13:23 > >> *收件人:* lidejun > >> *抄送:* users ; dev@dpdk.org; Lichunhe (Cloud Networking) < > >> lichunhe@huawei.com>; Wangliefeng > >> *主题:* Re: [dpdk-dev] IPV4/IPV6 TCP/UDP Pseudo Header Checksum APIs > >> > >> > >> > >> Realized my answer is confusing, I meant to say that code is correct as > >> pseudo ipv4/ipv6 headers for the purpose of checksum calculations doesn't > >> include options or extension headers, see udp wiki or corresponding rfcs > >> > >> > >> > >> https://en.wikipedia.org/wiki/User_Datagram_Protocol > >> > >> > >> > >> On Sat, Oct 20, 2018 at 10:42 AM Shyam Shrivastav < > >> shrivastav.shyam@gmail.com> wrote: > >> > >> that is correct , pseudo header doesn't include ipv4 options or ipv6 > >> extension headers .. > >> > >> > >> > >> On Sat, Oct 20, 2018 at 9:02 AM lidejun wrote: > >> > >> Has anybody used the following two APIs calculating ipv4&ipv6 tcp/udp > >> pseudo header checksum？ > >> > >> 1. rte_ipv4_phdr_cksum > >> > >> 2. rte_ipv6_phdr_cksum > >> The ipv4 version does not exclude ip options and ipv6 version does not > >> exclude extersion headers. > >> > >> >