[dpdk-users] [dpdk-dev] IPV4/IPV6 TCP/UDP Pseudo Header Checksum APIs

Hyong Youb Kim hyonkim at cisco.com
Wed Nov 28 16:07:19 CET 2018

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).


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.


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()..


More information about the users mailing list