From: Olivier MATZ <olivier.matz@6wind.com>
To: "Zhang, Helin" <helin.zhang@intel.com>,
Neil Horman <nhorman@tuxdriver.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC 01/17] mbuf: add definitions of unified packet types
Date: Tue, 20 Jan 2015 10:53:28 +0100 [thread overview]
Message-ID: <54BE2598.50608@6wind.com> (raw)
In-Reply-To: <F35DEAC7BCE34641BA9FAC6BCA4A12E70A7EB2A1@SHSMSX104.ccr.corp.intel.com>
Hi Helin,
On 01/20/2015 03:28 AM, Zhang, Helin wrote:
>> Another question I've asked several times[1][2] : what does having
>> RTE_PTYPE_TUNNEL_IP mean? What fields are checked by the hardware (or
>> the driver) and what fields should be checked by the application?
>> Are you sure that all the drivers (ixgbe, i40e, vmxnet3, enic) check the same
>> fields? (ethertype, ip version, ip len correct, ip checksum correct, flags, ...)
> RTE_PTYPE_TUNNEL_IP means hardware recognizes the received packet as an
> IP-in-IP packet.
> All the fields are filled by PMD which is recognized by hardware. The application
> can just use it which can save some cpu cycles to recognize the packet type by
> software.
> Drivers is responsible for filling with correct values according to the packet types
> recognized by its hardware. Different PMDs may fill with different values based on
> different capabilities.
Sorry, that does not answer to my question.
Let's take a simple example. Imagine a hardware-1 that is able to
recognize an IP packet by checking the ethertype and that the IP
version is set to 4.
Another hardware-2 recognize an IP packet by checking the ethertype,
the IP version and that the IP length is correct compared to m_len(m).
For the same packet, both hardwares will return RTE_PTYPE_L3_IPV4, but
they don't do the same checks on the packet. As I want my application
behave exactly the same whatever the hardware, I need to know what
checks are done in hardware, so I can decide what checks must be
done in my application.
Example of definition: RTE_PTYPE_L3_IPV4 means that ethertype is
0x0800 and IP.version is 4.
It means that I can skip these 2 tests in my application if I have
this packet_type, but all other checks must be done in software
(ip length, flags, checksum, ...)
For each packet type, we need a definition like above, and we must
check that all drivers setting a packet type behave like described.
Regards,
Olivier
next prev parent reply other threads:[~2015-01-20 9:53 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-19 3:23 [dpdk-dev] [RFC 00/17] unified packet type Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 01/17] mbuf: add definitions of unified packet types Helin Zhang
2015-01-19 16:19 ` Ananyev, Konstantin
2015-01-20 3:47 ` Zhang, Helin
2015-01-19 16:33 ` Neil Horman
2015-01-19 17:27 ` Olivier MATZ
2015-01-19 18:15 ` Neil Horman
2015-01-20 2:28 ` Zhang, Helin
2015-01-20 9:53 ` Olivier MATZ [this message]
2015-01-19 3:23 ` [dpdk-dev] [RFC 02/17] e1000: support of unified packet type Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 03/17] ixgbe: " Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 04/17] " Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 05/17] i40e: " Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 06/17] bond: " Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 07/17] enic: " Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 08/17] vmxnet3: " Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 09/17] app/test-pipeline: " Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 10/17] app/test-pmd: " Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 11/17] app/test: " Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 12/17] examples/ip_fragmentation: " Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 13/17] examples/ip_reassembly: " Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 14/17] examples/l3fwd-acl: " Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 15/17] examples/l3fwd-power: " Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 16/17] examples/l3fwd: " Helin Zhang
2015-01-19 3:23 ` [dpdk-dev] [RFC 17/17] mbuf: remove old packet type bit masks for ol_flags Helin Zhang
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=54BE2598.50608@6wind.com \
--to=olivier.matz@6wind.com \
--cc=dev@dpdk.org \
--cc=helin.zhang@intel.com \
--cc=nhorman@tuxdriver.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).