From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id CFE74255 for ; Wed, 14 Jan 2015 12:30:19 +0100 (CET) Received: by mail-wg0-f49.google.com with SMTP id n12so8319601wgh.8 for ; Wed, 14 Jan 2015 03:30:17 -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=60yfhqKlK1f5XOjan3OtRRRvmEPqrSLkcAwlYb/GFTk=; b=T710lCY88B8eXUABb0Gpm9p+kMqBL2Q8TqPojh6YGQq7oMTXoo5nXkCKmkUZoge/2a TzALUvjG6sC2KvNAS3MSlo13DxTJGJZR93VZXUZZNemsDpkjEnwGmnkK9Tr43FuYw+eT a74W/fEBlgC7NdqX0SAttBFMb2mjtJu9HtRukG1jtzIR7T4ZYntOy28LFD738AjOGt87 uo9uY1qmoKpwpoNKDPGK0j7esYQ6OlsogYGb5mjR6QxYOO+k7G3w/yB431hMsUrh7K0o h8ibRqLpD6kC6SLy27AqilYyyq6IARbQ1RVMkrm+Z3tChsYR/bsow6A2PlInbtl7lPCX 6w5Q== X-Gm-Message-State: ALoCoQlMgAFFa0ccLUSO39SgfqGJkUeixblYvD0EH9Xi1Fb2vKel7J2PwqcFLybefOQhEs9PY7p+ X-Received: by 10.194.61.231 with SMTP id t7mr5994607wjr.33.1421235017666; Wed, 14 Jan 2015 03:30:17 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id vj1sm29665728wjc.49.2015.01.14.03.30.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jan 2015 03:30:16 -0800 (PST) From: Thomas Monjalon To: Matthew Hall Date: Wed, 14 Jan 2015 12:29:55 +0100 Message-ID: <1735915.0Agkfn8QEd@xps13> Organization: 6WIND User-Agent: KMail/4.14.3 (Linux/3.17.6-1-ARCH; KDE/4.14.3; x86_64; ; ) In-Reply-To: <20150106052537.GB17455@mhcomputing.net> References: <5360787.ystvMoQ9V7@xps13> <20150106052537.GB17455@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 11:30:20 -0000 Hi Matthew, 2015-01-05 21:25, Matthew Hall: > > > 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. > > rte_hash_crc exists, rte_hash_crc_4byte exists, there is no rte_hash_ip_cksum > to use when checksum offloading doesn't work for some reason (in BSD it's > called in_cksum). The jhash and CRC API's don't look to be consistent / > compatible. An expandable API with some enum of hash algorithms and a standard > calling convention for accelerated / special algorithms (like ones which > assume 4-byte input) would make this more generic. [...] > But the larger architectural point was my proposed goal that all of the > various kinds of hashes (flow hashes, checksums / packet hashes, table lookup > hashes, etc.) could use a consistent pluggable API so we could easily move > back and forth between them and write clean consistent code any time a hash is > being used. Thank you for your detailed comments. Are you saying that you want to work on such hash API for DPDK? -- Thomas