From: Neil Horman <nhorman@tuxdriver.com>
To: Olivier MATZ <olivier.matz@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC 01/17] mbuf: add definitions of unified packet types
Date: Mon, 19 Jan 2015 13:15:02 -0500 [thread overview]
Message-ID: <20150119181502.GE21790@hmsreliant.think-freely.org> (raw)
In-Reply-To: <54BD3E66.3040709@6wind.com>
On Mon, Jan 19, 2015 at 06:27:02PM +0100, Olivier MATZ wrote:
> 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
>
> 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, ...)
>
> 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?
>
> 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.
>
> One naïve question: are we sure that at the end, using these complex
> packet types is faster than parsing the packet?
>
Thats an excellent question, especially when you start considering that high
layer stack functions will want to isolate themselves from these complex packet
types.
Neil
> 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-19 18:15 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 [this message]
2015-01-20 2:28 ` Zhang, Helin
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=20150119181502.GE21790@hmsreliant.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=dev@dpdk.org \
--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).