Re: IPv6 Offload Capabilities

[Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>]

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