From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 3C99E28F3 for ; Thu, 7 Jul 2016 10:48:46 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 07 Jul 2016 01:48:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,324,1464678000"; d="scan'208";a="990604078" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga001.jf.intel.com with ESMTP; 07 Jul 2016 01:48:45 -0700 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 7 Jul 2016 01:48:43 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 7 Jul 2016 01:48:43 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.147]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.8]) with mapi id 14.03.0248.002; Thu, 7 Jul 2016 16:48:39 +0800 From: "Liang, Cunming" To: Olivier MATZ , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 09/18] mbuf: support Mpls in software packet type parser Thread-Index: AQHR11UzF+JhbppQH0GTZTkKPXKaz6AKhAwAgAIeUSA= Date: Thu, 7 Jul 2016 08:48:39 +0000 Message-ID: References: <1467733310-20875-1-git-send-email-olivier.matz@6wind.com> <1467733310-20875-10-git-send-email-olivier.matz@6wind.com> <577CAE66.6050606@intel.com> <299f6d61-0ec4-dae4-d79d-fb746dc201b7@6wind.com> In-Reply-To: <299f6d61-0ec4-dae4-d79d-fb746dc201b7@6wind.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 09/18] mbuf: support Mpls in software packet type parser 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: Thu, 07 Jul 2016 08:48:46 -0000 Hi Olivier, > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Wednesday, July 06, 2016 4:00 PM > To: Liang, Cunming ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 09/18] mbuf: support Mpls in software pack= et > type parser >=20 > Hi Cunming, >=20 > On 07/06/2016 09:08 AM, Liang, Cunming wrote: > > Hi Olivier, > > > > On 7/5/2016 11:41 PM, Olivier Matz wrote: > >> Add a new RTE_PTYPE_L2_ETHER_MPLS packet type, and its support in > >> rte_pktmbuf_get_ptype(). > >> > >> Signed-off-by: Didier Pallard > >> Signed-off-by: Olivier Matz > >> --- > >> lib/librte_mbuf/rte_mbuf_ptype.c | 25 +++++++++++++++++++++++++ > >> lib/librte_mbuf/rte_mbuf_ptype.h | 9 ++++++++- > >> lib/librte_net/Makefile | 4 +++- > >> lib/librte_net/rte_ether.h | 2 ++ > >> 4 files changed, 38 insertions(+), 2 deletions(-) > >> > >> diff --git a/lib/librte_mbuf/rte_mbuf_ptype.c > >> b/lib/librte_mbuf/rte_mbuf_ptype.c > >> index 5d46608..0dea600 100644 > >> --- a/lib/librte_mbuf/rte_mbuf_ptype.c > >> +++ b/lib/librte_mbuf/rte_mbuf_ptype.c > >> @@ -41,6 +41,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> /* get l3 packet type from ip6 next protocol */ > >> static uint32_t > >> @@ -166,6 +167,9 @@ uint32_t rte_pktmbuf_get_ptype(const struct > >> rte_mbuf *m, > >> off =3D sizeof(*eh); > >> hdr_lens->l2_len =3D off; > >> + if (proto =3D=3D rte_cpu_to_be_16(ETHER_TYPE_IPv4)) > >> + goto l3; /* fast path if packet is IPv4 */ > >> + > >> if (proto =3D=3D rte_cpu_to_be_16(ETHER_TYPE_VLAN)) { > >> const struct vlan_hdr *vh; > >> struct vlan_hdr vh_copy; > >> @@ -189,8 +193,29 @@ uint32_t rte_pktmbuf_get_ptype(const struct > >> rte_mbuf *m, > >> off +=3D 2 * sizeof(*vh); > >> hdr_lens->l2_len +=3D 2 * sizeof(*vh); > >> proto =3D vh->eth_proto; > >> + } else if ((proto =3D=3D rte_cpu_to_be_16(ETHER_TYPE_MPLS)) || > >> + (proto =3D=3D rte_cpu_to_be_16(ETHER_TYPE_MPLSM))) { > >> + unsigned int i; > >> + const struct mpls_hdr *mh; > >> + struct mpls_hdr mh_copy; > >> + > >> +#define MAX_MPLS_HDR 5 > >> + for (i =3D 0; i < MAX_MPLS_HDR; i++) { > >> + mh =3D rte_pktmbuf_read(m, off + (i * sizeof(*mh)), > >> + sizeof(*mh), &mh_copy); > >> + if (unlikely(mh =3D=3D NULL)) > >> + return pkt_type; > >> + if (mh->bs) > >> + break; > >> + } > >> + if (i =3D=3D MAX_MPLS_HDR) > >> + return pkt_type; > >> + pkt_type =3D RTE_PTYPE_L2_ETHER_MPLS; > >> + hdr_lens->l2_len +=3D (sizeof(*mh) * (i + 1)); > > [LC] l2_len includes Eth, Vlan(opt.), MPLS(opt.). For VLAN and MPLS, it > > may include #n times overlay. > > These layer recognition knowledge are lost after the detection logic. > > Once the APP takes the ptype, for the layer(L2, L3, L4) which has more > > shim-layer, the xxx_len can't help to avoid the re-parse cost. >=20 > This is linked with the definition of packet type. Each layer has a > type, and here we associate it to a length (by the way the length is > something we may consider integrate inside the packet type in the future)= . [LC] Yes, I see.=20 My point is in some case, the length can represent for different layer. For who interests on L2 MPLS, the length layer scheme maybe can define as {= L2/MPLS/inner_L2/inner_L3}. The rte_mbuf_hdr_lens likes a meta data which associates with the specific = parser(assuming customized runtime instance provided by rte_pktmbuf_get_pty= pe). The provider understand the meaning and layout. =20 >=20 > The packet_type model allows to describe many packets kinds. Some will > be difficult to represent (ex: a packet with several different L2 or > L3). But I think this is a good compromise that could help the > application to get some information without looking inside the packet. >=20 > Changing the packet type structure to something more flexible/complex > would probably imply to loose time filling it in drivers and parse it in > the application. And we already have a structure that contains all the > information needed by the application: the packet data ;) [LC] Fully agree. Sometimes it's a tradeoff, if the offering meta data by p= arser is=20 not enough for further processing, the duplication packet data walking thro= ugh may happen. It's hard to define a meta data format for all cases. Probably the raw META= is a good choice, which is recognized by the parser provider. >=20 > In any case, this is not really the topic of the patchset, which just > provide a helper to parse a packet by software and get a packet_type (as > it is defined today). [LC] Maybe the conversation is a little beyond. Hope you get my point. Thanks. >=20 > Regards, > Olivier