From: "Zhang, Helin" <helin.zhang@intel.com>
To: Olivier MATZ <olivier.matz@6wind.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 02:28:43 +0000 [thread overview]
Message-ID: <F35DEAC7BCE34641BA9FAC6BCA4A12E70A7EB2A1@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <54BD3E66.3040709@6wind.com>
> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Tuesday, January 20, 2015 1:27 AM
> To: Neil Horman; Zhang, Helin
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC 01/17] mbuf: add definitions of unified packet
> types
>
> Hi,
>
> On 01/19/2015 05:33 PM, Neil Horman wrote:
> > On Mon, Jan 19, 2015 at 11:23:07AM +0800, Helin Zhang wrote:
> >> As there are only 6 bit flags in ol_flags for indicating packet
> >> types, which is not enough to describe all the possible packet types
> >> hardware can recognize. For example, i40e hardware can recognize more
> >> than 150 packet types. Unified packet type is composed of tunnel
> >> type, L3 type,
> >> L4 type and inner L3 type fields, and can be stored in 16 bits mbuf
> >> field of 'packet_type'.
> >>
> >> Signed-off-by: Helin Zhang <helin.zhang@intel.com>
> >> Signed-off-by: Cunming Liang <cunming.liang@intel.com>
> >> Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
> >> ---
> >> lib/librte_mbuf/rte_mbuf.h | 68
> >> ++++++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 68 insertions(+)
> >>
> >> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> >> index 16059c6..94eb38f 100644
> >> --- a/lib/librte_mbuf/rte_mbuf.h
> >> +++ b/lib/librte_mbuf/rte_mbuf.h
> >> @@ -165,6 +165,74 @@ extern "C" {
> >> /* Use final bit of flags to indicate a control mbuf */
> >> #define CTRL_MBUF_FLAG (1ULL << 63) /**< Mbuf contains
> control data */
> >>
> >> +/*
> >> + * Sixteen bits are divided into several fields to mark packet
> >> +types. Note that
> >> + * each field is indexical.
> >> + * - Bit 3:0 is for tunnel types.
> >> + * - Bit 7:4 is for L3 or outer L3 (for tunneling case) types.
> >> + * - Bit 10:8 is for L4 types. It can also be used for inner L4 types for
> >> + * tunneling packets.
> > This seems a bit sparse, in that the protocol field is 8 bits wide in a packet.
> > There are several common protocls that you don't have listed, and
> > you've already exhausted your namespace with the list you have.
> > Neil
I have reviewed all packet types supported in igb, ixgbe and i40e, and read the
code to get the packet types used in vmxnet3, bond, enic ,etc.
Current design can support all packet types used in above PMDs.
Yes, we don't have too many space reserved for future, but we can try to make
more bits for packet_type field later, as we can save 6 bits in ol_flags with this
patch set.
>
> 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.
>
> To be clearer: Let's say I have a network stack that parses and validates an IP
> packet. What tests can I remove if I get RTE_PTYPE_TUNNEL_IP?
That means it is a IP-in-IP tunnel packet, but not others. Also you can check other
fields in packet_type to get more information of the packet (e.g. L4 type).
>
> This question can be asked for all defined packet type. To be usable by an
> application, I think a formal definition would be needed. This is also important
> to know this for people wanting to develop a new PMD based on a new
> hardware. If the hardware does not behave exactly like ixgbe, i40e (I hope all
> drivers you implemented behave exactly the same), some work has to be done
> in the driver or the feature cannot be used.
The unified packet type defined here is aiming to support all hardwares. I40e has
different values from ixgbe. We can add more in the future if needed for future NICs.
>
> One naïve question: are we sure that at the end, using these complex packet
> types is faster than parsing the packet?
I guess yes for almost all cases, as hardware reported the packet types, and PMD
just puts the correct values into packet_type field.
Later, we will try to measure the differences.
Regards,
Helin
>
> Regards,
> Olivier
>
>
> [1] http://dpdk.org/ml/archives/dev/2014-November/008534.html
> [2] http://dpdk.org/ml/archives/dev/2014-November/008367.html
next prev parent reply other threads:[~2015-01-20 2:29 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 [this message]
2015-01-20 9:53 ` Olivier MATZ
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=F35DEAC7BCE34641BA9FAC6BCA4A12E70A7EB2A1@SHSMSX104.ccr.corp.intel.com \
--to=helin.zhang@intel.com \
--cc=dev@dpdk.org \
--cc=nhorman@tuxdriver.com \
--cc=olivier.matz@6wind.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).