From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH 09/18] mbuf: support Mpls in software packet type parser Date: Wed, 6 Jul 2016 10:00:08 +0200 Message-ID: <299f6d61-0ec4-dae4-d79d-fb746dc201b7@6wind.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit To: "Liang, Cunming" , dev@dpdk.org Return-path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id 849BD5A6B for ; Wed, 6 Jul 2016 10:00:10 +0200 (CEST) Received: by mail-wm0-f45.google.com with SMTP id z126so101586844wme.0 for ; Wed, 06 Jul 2016 01:00:10 -0700 (PDT) In-Reply-To: <577CAE66.6050606@intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Cunming, 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 = sizeof(*eh); >> hdr_lens->l2_len = off; >> + if (proto == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) >> + goto l3; /* fast path if packet is IPv4 */ >> + >> if (proto == 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 += 2 * sizeof(*vh); >> hdr_lens->l2_len += 2 * sizeof(*vh); >> proto = vh->eth_proto; >> + } else if ((proto == rte_cpu_to_be_16(ETHER_TYPE_MPLS)) || >> + (proto == 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 = 0; i < MAX_MPLS_HDR; i++) { >> + mh = rte_pktmbuf_read(m, off + (i * sizeof(*mh)), >> + sizeof(*mh), &mh_copy); >> + if (unlikely(mh == NULL)) >> + return pkt_type; >> + if (mh->bs) >> + break; >> + } >> + if (i == MAX_MPLS_HDR) >> + return pkt_type; >> + pkt_type = RTE_PTYPE_L2_ETHER_MPLS; >> + hdr_lens->l2_len += (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. 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). 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. 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 ;) 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). Regards, Olivier