Hi Gal and Matthew, 2015-01-05 00:09, Matthew Hall: > 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.
Which checksum are you talking about? IPv6 checsum doesn't exist. > 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. What are you talking about? > 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). Can we have the same performance with extended tables? Maybe you just want to implement your own 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). Please detail which function is missing for which usage. > 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. Again, a reference to the paper would help. -- Thomas