From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id A8BF05A6F for ; Mon, 19 Jan 2015 19:15:16 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YDGqt-0000kg-31; Mon, 19 Jan 2015 13:15:09 -0500 Date: Mon, 19 Jan 2015 13:15:02 -0500 From: Neil Horman To: Olivier MATZ Message-ID: <20150119181502.GE21790@hmsreliant.think-freely.org> 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> <54BD3E66.3040709@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <54BD3E66.3040709@6wind.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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 18:15:17 -0000 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 > >> 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? > 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 >