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 80CB12A9 for ; Mon, 5 Jan 2015 09:09:23 +0100 (CET) Received: from [192.168.1.77] (99-34-229-174.lightspeed.sntcca.sbcglobal.net [99.34.229.174]) by mail.mhcomputing.net (Postfix) with ESMTPSA id 62D0580BD96; Mon, 5 Jan 2015 00:07:11 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Matthew Hall In-Reply-To: Date: Mon, 5 Jan 2015 00:09:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "" X-Mailer: Apple Mail (2.1878.6) 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: Mon, 05 Jan 2015 08:09:23 -0000 On Jan 4, 2015, at 11:56 PM, Gal Sagie wrote: > I noticed that in version 1.8, there are no flags to indicate IPv6 = check > sum offloading > (only DEV_TX_OFFLOAD_IPV4_CKSUM) > which means TSO offloading is also not supported for IPv6. I need that feature too. Right now I disabled the IP checksum offloading = because I was making some greenfield code which does both protocol = versions cleanly, so it's not nice or polite to use real strange = asymmetric logic in there. Then I went looking and DPDK doesn't offer an accelerated user-space = routine for it. Which seems like it could work out quite poorly for = people trying to use ARM and PPC where the offloads might not be = present. I had to steal an unaccelerated one from *BSD just to get = things running until I could figure out a better way, which worked right = for IPv6 and ICMP datagrams so everything can use 100% the same clean = code. I think a bit more thought is needed around the various crypto / = checksum / hash features in DPDK in general for the future versions. 1) The hash table and LPM table have real strict limits about what kinds = of keys and values can be used. I have much bigger keys than the usual = classic packet keys (which I also need to support) and these won't work = in the DPDK's tables. It's a real bummer because I could use these for = implementing high speed logging and management protocols where I need to = access some funky keys and values at a very high perf rate, not just = extremely small ones at line-rate perf rate, as they've got now. It'd = also be good if they could work on bigger stuff like L4-L7 security = indicators (IPs work, domains, URLs, emails, MD5's, SHA256's, etc. don't = normally fit in DPDK's extremely locked down tables). 2) The checksum operations are kind of a hodgepodge and don't always = have a consistent vision to them... some things like the 16-bit-based IP = checksum appear to be missing any routine, including any accelerated one = when the offload doesn't work (like for ICMPv4, ICMPv6, and any IPv6 = datagrams, or other weird crap like IPv6 pseudo headers, even = contemplating those gives me a headache, but at least my greenfield code = for it works now). 3) There isn't a real flexible choice of hash functions for the things = which use hashes... for example, something which offered bidirectional = programming of the Flow Director hash algo by stock / default (as seen = in a paper one of the Intel guys posted recently) would be super = awesome. Matthew.=