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
