From: "Liang, Cunming" <cunming.liang@intel.com>
To: Olivier MATZ <olivier.matz@6wind.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 09/18] mbuf: support Mpls in software packet type parser
Date: Thu, 7 Jul 2016 08:48:39 +0000 [thread overview]
Message-ID: <D0158A423229094DA7ABF71CF2FA0DA315545242@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <299f6d61-0ec4-dae4-d79d-fb746dc201b7@6wind.com>
Hi Olivier,
> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Wednesday, July 06, 2016 4:00 PM
> To: Liang, Cunming <cunming.liang@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 09/18] mbuf: support Mpls in software packet
> type parser
>
> 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 <didier.pallard@6wind.com>
> >> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> >> ---
> >> 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 <rte_tcp.h>
> >> #include <rte_udp.h>
> >> #include <rte_sctp.h>
> >> +#include <rte_mpls.h>
> >> /* 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).
[LC] Yes, I see.
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_ptype).
The provider understand the meaning and layout.
>
> 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 ;)
[LC] Fully agree. Sometimes it's a tradeoff, if the offering meta data by parser is
not enough for further processing, the duplication packet data walking through 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.
>
> 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.
>
> Regards,
> Olivier
next prev parent reply other threads:[~2016-07-07 8:48 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-05 15:41 [dpdk-dev] [PATCH 00/18] software parser for packet type Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 01/18] doc: add template for release notes 16.11 Olivier Matz
2016-07-06 11:48 ` Mcnamara, John
2016-07-06 12:00 ` Olivier MATZ
2016-07-05 15:41 ` [dpdk-dev] [PATCH 02/18] mbuf: add function to read packet data Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 03/18] net: move Ethernet header definitions to the net library Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 04/18] mbuf: move packet type definitions in a new file Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 05/18] mbuf: add function to get packet type from data Olivier Matz
2016-07-06 6:44 ` Liang, Cunming
2016-07-06 7:42 ` Olivier MATZ
2016-07-06 11:59 ` Chilikin, Andrey
2016-07-06 12:08 ` Olivier MATZ
2016-07-06 12:21 ` Chilikin, Andrey
2016-07-07 8:19 ` Liang, Cunming
2016-07-07 15:48 ` Olivier Matz
2016-07-08 10:08 ` Liang, Cunming
2016-07-05 15:41 ` [dpdk-dev] [PATCH 06/18] mbuf: support Vlan in software packet type parser Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 07/18] mbuf: support QinQ " Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 08/18] net: add Mpls header structure Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 09/18] mbuf: support Mpls in software packet type parser Olivier Matz
2016-07-06 7:08 ` Liang, Cunming
2016-07-06 8:00 ` Olivier MATZ
2016-07-07 8:48 ` Liang, Cunming [this message]
2016-07-07 16:01 ` Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 10/18] mbuf: support Ip tunnels " Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 11/18] net: add Gre header structure Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 12/18] mbuf: support Gre in software packet type parser Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 13/18] mbuf: support Nvgre " Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 14/18] mbuf: get ptype for the first layers only Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 15/18] mbuf: add functions to dump packet type Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 16/18] mbuf: clarify definition of fragment packet types Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 17/18] app/testpmd: dump ptype using the new function Olivier Matz
2016-07-05 15:41 ` [dpdk-dev] [PATCH 18/18] app/testpmd: display sw packet type Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 00/16] software parser for " Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 01/16] mbuf: add function to read packet data Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 02/16] net: move Ethernet header definitions to the net library Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 03/16] mbuf: move packet type definitions in a new file Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 04/16] net: introduce net library Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 05/16] net: add function to get packet type from data Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 06/16] net: support Vlan in software packet type parser Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 07/16] net: support QinQ " Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 08/16] net: support Ip tunnels " Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 09/16] net: add Gre header structure Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 10/16] net: support Gre in software packet type parser Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 11/16] net: support Nvgre " Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 12/16] net: get ptype for the first layers only Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 13/16] mbuf: add functions to dump packet type Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 14/16] mbuf: clarify definition of fragment packet types Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 15/16] app/testpmd: dump ptype using the new function Olivier Matz
2016-08-29 14:35 ` [dpdk-dev] [PATCH v2 16/16] app/testpmd: display software packet type Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 00/16] software parser for " Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 01/16] mbuf: add function to read packet data Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 02/16] net: move Ethernet header definitions to the net library Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 03/16] mbuf: move packet type definitions in a new file Olivier Matz
2016-10-10 14:52 ` Thomas Monjalon
2016-10-11 9:01 ` Olivier MATZ
2016-10-11 15:51 ` Thomas Monjalon
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 04/16] net: introduce net library Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 05/16] net: add function to get packet type from data Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 06/16] net: support Vlan in software packet type parser Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 07/16] net: support QinQ " Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 08/16] net: support Ip tunnels " Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 09/16] net: add Gre header structure Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 10/16] net: support Gre in software packet type parser Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 11/16] net: support Nvgre " Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 12/16] net: get ptype for the first layers only Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 13/16] mbuf: add functions to dump packet type Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 14/16] mbuf: clarify definition of fragment packet types Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 15/16] app/testpmd: dump ptype using the new function Olivier Matz
2016-10-03 8:38 ` [dpdk-dev] [PATCH v3 16/16] app/testpmd: display software packet type Olivier Matz
2016-10-11 16:24 ` [dpdk-dev] [PATCH v3 00/16] software parser for " Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D0158A423229094DA7ABF71CF2FA0DA315545242@shsmsx102.ccr.corp.intel.com \
--to=cunming.liang@intel.com \
--cc=dev@dpdk.org \
--cc=olivier.matz@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).