From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: [RFC 01/17] mbuf: add definitions of unified packet types Date: Mon, 19 Jan 2015 13:15:02 -0500 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-Transfer-Encoding: quoted-printable Cc: dev-VfR2kkLFssw@public.gmane.org To: Olivier MATZ Return-path: Content-Disposition: inline In-Reply-To: <54BD3E66.3040709-pdR9zngts4EAvxtiuMwx3w@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" On Mon, Jan 19, 2015 at 06:27:02PM +0100, Olivier MATZ wrote: > Hi, >=20 > 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 type= s, > >> which is not enough to describe all the possible packet types hardwa= re > >> can recognize. For example, i40e hardware can recognize more than 15= 0 > >> packet types. Unified packet type is composed of tunnel type, L3 typ= e, > >> 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 contro= l data */ > >> =20 > >> +/* > >> + * Sixteen bits are divided into several fields to mark packet type= s. 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 typ= es 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 >=20 > 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, ...) >=20 > 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? >=20 > 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. >=20 > One na=EFve question: are we sure that at the end, using these complex > packet types is faster than parsing the packet? >=20 Thats an excellent question, especially when you start considering that h= igh layer stack functions will want to isolate themselves from these complex = packet types. Neil > Regards, > Olivier >=20 >=20 > [1] http://dpdk.org/ml/archives/dev/2014-November/008534.html > [2] http://dpdk.org/ml/archives/dev/2014-November/008367.html >=20