Post by Thomas MonjalonWhich checksum are you talking about? IPv6 checsum doesn't exist.
The same computation algorithm must be reused to calculate the IPV6
Pseudoheader checksum when generating ICMPV6, UDPV6, and other L4 protocols
whose definitions were retroactively modified to include the IPV6
pseudoheader, that happen to use the same checksum in L4 which IP used in L3.
Post by Thomas MonjalonPost by Matthew HallThen 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?
Yeah this is referring to the IP checksum algorithm, "the ones' complement of
the ones' complement sum of some 16-bit words". I didn't find a speedy version
of it for manually hacking together IPV6 based frames anyplace inside DPDK.
Post by Thomas MonjalonCan we have the same performance with extended tables?
Maybe you just want to implement your own tables.
One thing is for sure. People using DPDK are not going to be Intel
acceleration experts. If we were we wouldn't need to use DPDK. ;)
Therefore any table that comes with DPDK is definitely going to be using
better optimizations than whatever we come up with on our own, not to mention
reinventing the wheel incompatibly is a bad thing, despite that many C
developers like to do so. ;)
I'm a security expert but I'm not an Intel-friendly hash table expert. It
would be totally OK if the table didn't run as fast when bigger stuff was
used, but right now big stuff is just prohibited with a bunch of hard-coded
sizes and this seems like a bad thing.
Post by Thomas MonjalonPost by Matthew Hall2) 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.
Post by Thomas MonjalonPost by Matthew Hall3) 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.
http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf
Mentioned by jim at netgate.com (Jim Thompson) .
To sum up the paper, there is a special way to set up the Flow Director hash,
which barely changes packet evenness from the default setting, which will get
both directions of L4 flows routed into the same CPU cores.
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.
Matthew.