From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f68.google.com (mail-oi0-f68.google.com [209.85.218.68]) by dpdk.org (Postfix) with ESMTP id C4A8B1B19D for ; Thu, 28 Sep 2017 15:43:18 +0200 (CEST) Received: by mail-oi0-f68.google.com with SMTP id p126so2285893oih.9 for ; Thu, 28 Sep 2017 06:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2GlQnr91Xg30JNvnXlTwN5YjSISiqVLCDlwrLrJvNYw=; b=VTUlypAewRy/k5w1d0VfanC45DjUC1tURINzJ5vHy7uy/XfvbAPVZVm+APKz2n5etU RDOCeYvfSJgt/3Mr6T/2tUeplepI9Ih3BhsVgxaB9/Fu1CHtPNlKUFBur/ENxyD9FZhS O7JcX8LemejJLdUvu3SGYT/F0zf0knbDpXBzezveznqq/kwtmfSSfzs1iABssJoEnf8z b98nxXPyo6vyYFd9eDnFlt1AT3PAS7HqjXYUKvR1Diwtx7J6q/Pb1lQMY+acRg63GWey W3ZMiaRF5Xv6U0Kn0BGhiCXauI0BrDSS3Me2hZD7QwsFCLR8GjaXrsvLHixLG//SaBON h7nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2GlQnr91Xg30JNvnXlTwN5YjSISiqVLCDlwrLrJvNYw=; b=ZtAcWos/0owlrgCYcj90iBzez3n4of8L7/Qa8pe7W8HR/VLDkGMsCT49R1llQBeNlv nM+p/lLRqZzhXn290FME/MQa+BVsck+4fpPsNwl4Q6rvZQ6dqmi4nf8gzgfAtDRdnS9t 9nMT6vkNT8oKAwAub8VNj613ZLGXpWY2gG/q2lL2Vs8mJ7BwAzlvBh4Resl7gfp9XSiy /DVtBpmD+AInAqtFmXj7VdWP65dcZX9SdTpWkPd+Icv2Cva11UPQjkj/Dly37YrMZGk7 1gh8fViildpe+hdmb8c2ogl3l0HLvndfqhxIRy8oWWLxEv/QJxUz7ir5G00KQ7dqtCC6 kzIw== X-Gm-Message-State: AMCzsaWkEKM2SjO63VdgQNxhncpjqPyF1iHJeYVDvifFrZYq99Ot7FwP YbUKPLXuZsOVh/qksg614QVDWHACH+B/wnzbsQwIr1kU X-Google-Smtp-Source: AOwi7QDWZimu3SqYVAVeObCdrMobxs+Juu4nzHfh/nD8xFLCgO8FVkCr2TSptSgwo2/US246Llx/g0RVUCam5BwOzNM= X-Received: by 10.202.63.132 with SMTP id m126mr383839oia.137.1506606197949; Thu, 28 Sep 2017 06:43:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.83.193 with HTTP; Thu, 28 Sep 2017 06:43:17 -0700 (PDT) In-Reply-To: <1506586406-127542-5-git-send-email-beilei.xing@intel.com> References: <1506565054-67690-1-git-send-email-beilei.xing@intel.com> <1506586406-127542-1-git-send-email-beilei.xing@intel.com> <1506586406-127542-5-git-send-email-beilei.xing@intel.com> From: Sean Harte Date: Thu, 28 Sep 2017 14:43:17 +0100 Message-ID: To: Beilei Xing Cc: jingjing.wu@intel.com, andrey.chilikin@intel.com, dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v5 4/8] ethdev: add GTP items to support flow API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 13:43:19 -0000 On 28 September 2017 at 09:13, Beilei Xing wrote: > This patch adds GTP, GTPC and GTPU items for > generic flow API, and also exposes item fields > through the flow command. > > Signed-off-by: Beilei Xing > Acked-by: Adrien Mazarguil > --- > app/test-pmd/cmdline_flow.c | 40 ++++++++++++++++++++++ > app/test-pmd/config.c | 3 ++ > doc/guides/prog_guide/rte_flow.rst | 18 ++++++++++ > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 4 +++ > lib/librte_ether/rte_flow.h | 52 +++++++++++++++++++++++++++++ > 5 files changed, 117 insertions(+) > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -955,6 +955,24 @@ Usage example, fuzzy match a TCPv4 packets: > | 4 | END | > +-------+----------+ > > +Item: ``GTP``, ``GTPC``, ``GTPU`` > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > +Matches a GTP header. > + > +Note: GTP, GTPC and GTPU use the same structure. Since only UDP destination port > +is used to distinguish GTP_C (port is 2123) and GTP_U packets (port is 2152), > +GTPC and GTPU item are defined for a user-friendly API when creating GTP-C and > +GTP-U flow. In GTPv1-C, request messages are sent from any port to port 2123, and in the response message the ports are reversed (in GTPv2-C, it's a little more complicated). Is the intention to only match requests? It's not clear. Also, it should be mentioned that GTPv0 is not included (it uses port 3386) > + > +- ``v_pt_rsv_flags``: version (3b), protocol type (1b), reserved (1b), > + extension header flag (1b), sequence number flag (1b), N-PDU number > + flag (1b). > +- ``msg_type``: message type. > +- ``msg_len``: message length. > +- ``teid``: tunnel endpoint identifier. > +- Default ``mask`` matches teid only. > + > Actions > ~~~~~~~ > > /** > + * RTE_FLOW_ITEM_TYPE_GTP. > + * > + * Matches a GTP header. > + */ > +struct rte_flow_item_gtp { > + /** > + * Version (2b), protocol type (1b), reserved (1b), > + * Extension header flag (1b), > + * Sequence number flag (1b), > + * N-PDU number flag (1b). > + */ > + uint8_t v_pt_rsv_flags; The version field has 3 bits, not 2 (it was correct above). The meaning of the 5 flags in this byte is different in GTPv2-C compared to GTPv1-C. Is the intention to only support GTPv1? If so that should be stated. If GTPv2 is supported, then the teid field below is not present in a few cases and matching on it could cause some strange behaviour. > + uint8_t msg_type; /**< Message type. */ > + rte_be16_t msg_len; /**< Message length. */ > + rte_be32_t teid; /**< Tunnel endpoint identifier. */ > +}; > + > +/** Default mask for RTE_FLOW_ITEM_TYPE_GTP. */ > +#ifndef __cplusplus > +static const struct rte_flow_item_gtp rte_flow_item_gtp_mask = { > + .teid = RTE_BE32(0xffffffff), > +}; > +#endif > + > +/** > * Matching pattern item definition. > * > * A pattern is formed by stacking items starting from the lowest protocol > -- > 2.5.5 >