From: Olivier Matz <olivier.matz@6wind.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: Shyam Shrivastav <shrivastav.shyam@gmail.com>,
lidejun1@huawei.com, users <users@dpdk.org>,
dev@dpdk.org, lichunhe@huawei.com, zhangxufeng4@huawei.com
Subject: Re: [dpdk-users] [dpdk-dev] IPV4/IPV6 TCP/UDP Pseudo Header Checksum APIs
Date: Tue, 23 Oct 2018 11:01:58 +0200 [thread overview]
Message-ID: <20181023090158.z5w3gtvdzax247w6@platinum> (raw)
In-Reply-To: <bf22fb5e-cefd-c7f1-07aa-a059c98d0692@intel.com>
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
On Mon, Oct 22, 2018 at 09:03:14AM +0100, Ferruh Yigit wrote:
> On 10/20/2018 7:30 AM, Shyam Shrivastav wrote:
> > Yes you are right, I misread, following code (ipv4 case) assumes no ip
> > options while calculating pseudo hdr length field
> >
> > psd_hdr.len = rte_cpu_to_be_16(
> > (uint16_t)(rte_be_to_cpu_16(ipv4_hdr->total_length)
> > - sizeof(struct ipv4_hdr)));
> >
> > should be
> >
> > psd_hdr.len = rte_cpu_to_be_16(
> > (uint16_t)(rte_be_to_cpu_16(ipv4_hdr->total_length)
> > - (ipv4_hdr->version_ihl & 0x0f)*4)));
>
> cc'ed maintainer of the that part, Olivier.
>
> >
> > On Sat, Oct 20, 2018 at 11:44 AM lidejun <lidejun1@huawei.com> wrote:
> >
> >> I mean DPDK APIs do not exclude ipv4 options or ipv6 extension headers, it
> >> is bug?
> >>
> >>
> >>
> >> *发件人:* Shyam Shrivastav [mailto:shrivastav.shyam@gmail.com]
> >> *发送时间:* 2018年10月20日 13:23
> >> *收件人:* lidejun <lidejun1@huawei.com>
> >> *抄送:* users <users@dpdk.org>; dev@dpdk.org; Lichunhe (Cloud Networking) <
> >> lichunhe@huawei.com>; Wangliefeng <wangliefeng@huawei.com>
> >> *主题:* Re: [dpdk-dev] IPV4/IPV6 TCP/UDP Pseudo Header Checksum APIs
> >>
> >>
> >>
> >> Realized my answer is confusing, I meant to say that code is correct as
> >> pseudo ipv4/ipv6 headers for the purpose of checksum calculations doesn't
> >> include options or extension headers, see udp wiki or corresponding rfcs
> >>
> >>
> >>
> >> https://en.wikipedia.org/wiki/User_Datagram_Protocol
> >>
> >>
> >>
> >> On Sat, Oct 20, 2018 at 10:42 AM Shyam Shrivastav <
> >> shrivastav.shyam@gmail.com> wrote:
> >>
> >> that is correct , pseudo header doesn't include ipv4 options or ipv6
> >> extension headers ..
> >>
> >>
> >>
> >> On Sat, Oct 20, 2018 at 9:02 AM lidejun <lidejun1@huawei.com> wrote:
> >>
> >> Has anybody used the following two APIs calculating ipv4&ipv6 tcp/udp
> >> pseudo header checksum?
> >>
> >> 1. rte_ipv4_phdr_cksum
> >>
> >> 2. rte_ipv6_phdr_cksum
> >> The ipv4 version does not exclude ip options and ipv6 version does not
> >> exclude extersion headers.
> >>
> >>
>
next prev parent reply other threads:[~2018-10-23 9:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-20 3:32 [dpdk-users] " lidejun
2018-10-20 5:12 ` [dpdk-users] [dpdk-dev] " Shyam Shrivastav
2018-10-20 5:22 ` Shyam Shrivastav
2018-10-20 6:14 ` [dpdk-users] 答复: " lidejun
2018-10-20 6:30 ` [dpdk-users] " Shyam Shrivastav
2018-10-22 8:03 ` Ferruh Yigit
2018-10-23 9:01 ` Olivier Matz [this message]
2018-10-23 10:53 ` Shyam Shrivastav
2018-11-28 15:07 ` Hyong Youb Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181023090158.z5w3gtvdzax247w6@platinum \
--to=olivier.matz@6wind.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=lichunhe@huawei.com \
--cc=lidejun1@huawei.com \
--cc=shrivastav.shyam@gmail.com \
--cc=users@dpdk.org \
--cc=zhangxufeng4@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).