On Jan 4, 2015, at 11:56 PM, Gal Sagie <gal.sagie at 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. 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. 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). 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). 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. Matthew.
