DPDK patches and discussions
 help / color / mirror / Atom feed
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

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