On Tue, Oct 23, 2018 at 11:01:58AM +0200, Olivier Matz wrote: > Hi, > > You are right, the current code does not take IP or IPv6 options > in account. I think this should be considered as a bug. > > The fix for IPv4 is not complicated, I did a quick draft here: > http://git.droids-corp.org/?p=dpdk.git;a=commitdiff;h=96a6978ef6814e1450e1bd65fbce91c3d85b3121 > > For IPv6, it is more complex than expected: > https://tools.ietf.org/html/rfc2460.html#section-8.1 > > - we need to skip extension headers > - we need to parse routing headers and use the proper destination > address in the pseudo header checksum > > This makes me think that the API is not adequate. Asking the user > to provide the headers in a contiguous memory without specifying > the length is quite dangerous, especially if the header comes from > outside, as it can trigger out of bound accesses. > > I wonder if we shouldn't switch to a mbuf based API instead, and > deprecate the old one. > > Thoughts? > Olivier >
I have been looking into a similar issue because rte_net_intel_cksum_prepare(), which is used by most tx_pkt_prepare handlers, does not work when ipv6 extensions are present. That function is using rte_ipv6_phdr_cksum(). And this makes rte_eth_tx_prepare() kinda useless for any workloads that encounter ipv6 extensions. There are 2 routing header types now (2 and 3). https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-3 In addition to these routing headers, there is also ipv6 mobility. Pseudo header's source address is supposed to be the address in the Home Address option. https://tools.ietf.org/html/rfc6275#page-36 Who knows there may be future extensions that affect pseudo header.. We can probably make rte_ipv6_phdr_cksum() to understand all existing headers that affect pseudo header, but it will still not be future proof. Should at least document the limitations for rte_ipv6_phdr_cksum().. -Hyong
