From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas.monjalon@6wind.com> Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by dpdk.org (Postfix) with ESMTP id 966145938 for <dev@dpdk.org>; Mon, 5 Jan 2015 09:37:16 +0100 (CET) Received: by mail-we0-f175.google.com with SMTP id k11so7324835wes.6 for <dev@dpdk.org>; Mon, 05 Jan 2015 00:37:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=40KIH/o/jBjwJrK015f5gbluJGpLykzlMzZm8GmWYqs=; b=ZXFgs/kXHY2TssV66BVAKFE19mPN3Qy2szyarZfRyS8ZY/QE/HVEgHz+LhqAT/r230 L45weHoga2QPNkTWUaZ17iWqmFIb1Y590rMlY+RxNY4uYfwPpjCLhnlb1vCNXKvxwgz3 oL60Mau0+i4E0jz6WukWcm4+hMFYHVmW/8T02A7BWkDJ/Yqxq0OzicqUucQg8L3cWhiX 3jwEbZmcuKsH93MvwhKgNj3lSOu7ijLOzLxAJhZb9orKkM/dY3POyRaoXsTbWa0FkDvj RuiBPaA3aX50VFM/gFlOehQtbQGK52jVFchrUo8wpASFy9u19NooeaPc3My69tx4+CNd t7pQ== X-Gm-Message-State: ALoCoQlg3BV81cOPHtJF0/De7lQKCyGrSVpZiQ6MhIvWJTxVvfvxuQg5FldEwuR9yNQA0LeinJTI X-Received: by 10.194.88.131 with SMTP id bg3mr171397212wjb.99.1420447036418; Mon, 05 Jan 2015 00:37:16 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id u3sm8956841wiw.24.2015.01.05.00.37.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jan 2015 00:37:15 -0800 (PST) From: Thomas Monjalon <thomas.monjalon@6wind.com> To: Matthew Hall <mhall@mhcomputing.net>, Gal Sagie <gal.sagie@gmail.com> Date: Mon, 05 Jan 2015 09:36:54 +0100 Message-ID: <5360787.ystvMoQ9V7@xps13> Organization: 6WIND User-Agent: KMail/4.14.3 (Linux/3.17.6-1-ARCH; KDE/4.14.3; x86_64; ; ) In-Reply-To: <C6595EEB-8329-49F9-9745-52887AE9F848@mhcomputing.net> References: <CAG9LJa6qY=LeiN+sPQGx7ok-RWwf9uXm_Vz4-2NLTW8XvGoU5w@mail.gmail.com> <C6595EEB-8329-49F9-9745-52887AE9F848@mhcomputing.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 05 Jan 2015 08:37:16 -0000 Hi Gal and Matthew, 2015-01-05 00:09, Matthew Hall: > On Jan 4, 2015, at 11:56 PM, Gal Sagie <gal.sagie@gmail.com> 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. Which checksum are you talking about? IPv6 checsum doesn't exist. > 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. What are you talking about? > 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). Can we have the same performance with extended tables? Maybe you just want to implement your own 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). Please detail which function is missing for which usage. > 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. Again, a reference to the paper would help. -- Thomas