From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id CF9CE5A8E for ; Mon, 19 Jan 2015 18:27:16 +0100 (CET) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YDGA2-0005Nd-QY; Mon, 19 Jan 2015 18:30:52 +0100 Message-ID: <54BD3E66.3040709@6wind.com> Date: Mon, 19 Jan 2015 18:27:02 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Neil Horman , Helin Zhang References: <1421637803-17034-1-git-send-email-helin.zhang@intel.com> <1421637803-17034-2-git-send-email-helin.zhang@intel.com> <20150119163306.GD21790@hmsreliant.think-freely.org> In-Reply-To: <20150119163306.GD21790@hmsreliant.think-freely.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [RFC 01/17] mbuf: add definitions of unified packet types X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 17:27:16 -0000 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 >> Signed-off-by: Cunming Liang >> Signed-off-by: Jijiang Liu >> --- >> 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? Regards, Olivier [1] http://dpdk.org/ml/archives/dev/2014-November/008534.html [2] http://dpdk.org/ml/archives/dev/2014-November/008367.html