Re: IPv6 Offload Capabilities

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

Hi Gal and Matthew,

2015-01-05 00:09, Matthew Hall:
> On Jan 4, 2015, at 11:56 PM, Gal Sagie <gal.sagie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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