From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <hyonkim@cisco.com> Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by dpdk.org (Postfix) with ESMTP id A8B291B430; Wed, 28 Nov 2018 16:07:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2003; q=dns/txt; s=iport; t=1543417645; x=1544627245; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=gZObe7rLGWaJKqsF8AykdbLX1kEPvrm6ecFe4znK27Q=; b=Rh5fA8hAnO6/BdSUDAqWTAlmPdTBb5OQ49rGGrGC16AfRtBItdAS5Z1l ZhGdjxGnEArGrmbb6ef7KL1BRv7Rn6GddoSXvuk2g+nZ2glcgoVSCjyYo XUhrdCOzYNsTzu3vcoY+77zppHxgNsaWsRXtJYJ/Zwi+KOLKRImaypLMc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADNrf5b/4kNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVopZk8zJ4wRjAmCDZdCFIFmCwEBJYR?= =?us-ascii?q?HAoMsIjQJDQEDAQECAQECbRwMhT0BBTo/EAsYCQwZDwVJgzWCAQ+ndYQxAoY?= =?us-ascii?q?KjBYRBoFAP4Qjgx4BAQIBF4ECgQSCdoImApAakAEJhn2KKSORFY1Uik0CBAY?= =?us-ascii?q?FAhSBRjg7gRozGggbFYI/aQiCHhd/AQiHVoVOMAMwAQEIjjABAQ?= X-IronPort-AV: E=Sophos;i="5.56,290,1539648000"; d="scan'208";a="205563146" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Nov 2018 15:07:24 +0000 Received: from HYONKIM-7R0DR.cisco.com ([10.24.37.117]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id wASF7JAD002702 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Nov 2018 15:07:22 GMT Date: Thu, 29 Nov 2018 00:07:19 +0900 From: Hyong Youb Kim <hyonkim@cisco.com> To: Olivier Matz <olivier.matz@6wind.com> Cc: Ferruh Yigit <ferruh.yigit@intel.com>, Shyam Shrivastav <shrivastav.shyam@gmail.com>, lidejun1@huawei.com, users <users@dpdk.org>, dev@dpdk.org, lichunhe@huawei.com, zhangxufeng4@huawei.com Message-ID: <20181128150718.GA25832@HYONKIM-7R0DR.cisco.com> References: <A69E93D1CF6DFA4BA33FB8D8DAFFFD19035A0280@dggemm512-mbx.china.huawei.com> <CAGSp03nOTeCO8xdJ8wbhi+Z2_6kMAyhYYNQvV9BaFS=txFn4dg@mail.gmail.com> <CAGSp03ncwhn4ZxHtqnMoZEVJYQjc27bcWwVBvhwstpzyJWa67w@mail.gmail.com> <A69E93D1CF6DFA4BA33FB8D8DAFFFD19035A0973@dggemm512-mbx.china.huawei.com> <CAGSp03mCDamL2a=fSq=1rRd+_tdPLbsnY+2CsA6aYpd5vU3RwQ@mail.gmail.com> <bf22fb5e-cefd-c7f1-07aa-a059c98d0692@intel.com> <20181023090158.z5w3gtvdzax247w6@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181023090158.z5w3gtvdzax247w6@platinum> User-Agent: Mutt/1.10.0 (2018-05-17) X-Outbound-SMTP-Client: 10.24.37.117, [10.24.37.117] X-Outbound-Node: alln-core-4.cisco.com Subject: Re: [dpdk-dev] [dpdk-users] IPV4/IPV6 TCP/UDP Pseudo Header Checksum APIs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 28 Nov 2018 15:07:26 -0000 On Tue, Oct 23, 2018 at 11:01:58AM +0200, Olivier Matz wrote: > 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 > I have been looking into a similar issue because rte_net_intel_cksum_prepare(), which is used by most tx_pkt_prepare handlers, does not work when ipv6 extensions are present. That function is using rte_ipv6_phdr_cksum(). And this makes rte_eth_tx_prepare() kinda useless for any workloads that encounter ipv6 extensions. There are 2 routing header types now (2 and 3). https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-3 In addition to these routing headers, there is also ipv6 mobility. Pseudo header's source address is supposed to be the address in the Home Address option. https://tools.ietf.org/html/rfc6275#page-36 Who knows there may be future extensions that affect pseudo header.. We can probably make rte_ipv6_phdr_cksum() to understand all existing headers that affect pseudo header, but it will still not be future proof. Should at least document the limitations for rte_ipv6_phdr_cksum().. -Hyong