From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.46.186]) by dpdk.org (Postfix) with ESMTP id A5CE3590C for ; Tue, 6 Jan 2015 06:32:39 +0100 (CET) Received: by mail.mhcomputing.net (Postfix, from userid 1000) id 3AA8180BD96; Mon, 5 Jan 2015 21:30:27 -0800 (PST) Date: Mon, 5 Jan 2015 21:30:27 -0800 From: Matthew Hall To: Thomas Monjalon Message-ID: <20150106053027.GC17455@mhcomputing.net> References: <5360787.ystvMoQ9V7@xps13> <20150106052537.GB17455@mhcomputing.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150106052537.GB17455@mhcomputing.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] IPv6 Offload Capabilities 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: Tue, 06 Jan 2015 05:32:39 -0000 On Mon, Jan 05, 2015 at 09:25:37PM -0800, Matthew Hall wrote: > The same computation algorithm must be reused to calculate the IPV6 > Pseudoheader checksum when generating ICMPV6, UDPV6, and other L4 protocols > whose definitions were retroactively modified to include the IPV6 > pseudoheader, that happen to use the same checksum in L4 which IP used in L3. To clarify, this is the part of the RFC which mentions it: https://tools.ietf.org/html/rfc2460#section-8.1 Also, somebody else mentioned using TSO (TCP Segmentation Offload). I did look at it but since it only seemed to work in TCP if I read everything right, that'd mean I had inconsistent code for IPv4 versus IPv6 stack, and inconsistent behavior for TCP from that for ICMP and UDP. I was trying to avoid writing too much of this messy code if possible. Matthew.