From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E768AC433E0 for ; Fri, 26 Mar 2021 13:13:02 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 4F51061A05 for ; Fri, 26 Mar 2021 13:13:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4F51061A05 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 32BDD40685; Fri, 26 Mar 2021 14:13:00 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id 75A3D4067B; Fri, 26 Mar 2021 14:12:58 +0100 (CET) IronPort-SDR: lPY7KGGbTyl2Qd9JkYvUK6gms4SklQvFVRe2PUYLx6Ze066HMMUzZjgZS5ru7JhlFfdFpkdqcV IrCiRYE8pGYA== X-IronPort-AV: E=McAfee;i="6000,8403,9934"; a="178261520" X-IronPort-AV: E=Sophos;i="5.81,280,1610438400"; d="scan'208";a="178261520" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2021 06:12:56 -0700 IronPort-SDR: 1NIrXklyPn76t+OcWmzTbF0Hdnb3sl54mNB/TPC3rPOBfGglVRpVGcq2xpWUOQ8PnVKO1Bwi6K 5cXrzOTpbMkQ== X-IronPort-AV: E=Sophos;i="5.81,280,1610438400"; d="scan'208";a="375481708" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.231.99]) ([10.213.231.99]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2021 06:12:52 -0700 To: Raslan Darawsheh , dev@dpdk.org, Ori Kam , Andrew Rybchenko , Ivan Malov Cc: viacheslavo@nvidia.com, shirik@nvidia.com, ying.a.wang@intel.com, stable@dpdk.org, Thomas Monjalon , Olivier Matz References: <20210323121134.19113-1-rasland@nvidia.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <20780a26-f27a-8d43-27e3-744293538cca@intel.com> Date: Fri, 26 Mar 2021 13:12:48 +0000 MIME-Version: 1.0 In-Reply-To: <20210323121134.19113-1-rasland@nvidia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] ethdev: update qfi definition X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 3/23/2021 12:11 PM, Raslan Darawsheh wrote: > qfi field is 8 bits which represent single bit for > PPP (paging Policy Presence) single bit for RQI > (Reflective QoS Indicator) and 6 bits for qfi > (QoS Flow Identifier) Can you please put a reference for above information? > > This update the doxygen format and the mask for qfi > to properly identify the full 8 bits of the field. > > note: changing the default mask would cause different > patterns generated by testpmd. > > Fixes: 346553db5bd1 ("ethdev: add GTP extension header to flow API") > Cc: ying.a.wang@intel.com > Cc: stable@dpdk.org > > Signed-off-by: Raslan Darawsheh > --- > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 3 ++- > lib/librte_ethdev/rte_flow.h | 4 ++-- > 2 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > index f59eb8a27d..dd39c4c3c2 100644 > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > @@ -3742,7 +3742,8 @@ This section lists supported pattern items and their attributes, if any. > - ``gtp_psc``: match GTP PDU extension header with type 0x85. > > - ``pdu_type {unsigned}``: PDU type. > - - ``qfi {unsigned}``: QoS flow identifier. > + > + - ``qfi {unsigned}``: PPP, RQI and QoS flow identifier. > > - ``pppoes``, ``pppoed``: match PPPoE header. > > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h > index 669e677e91..79106e0246 100644 > --- a/lib/librte_ethdev/rte_flow.h > +++ b/lib/librte_ethdev/rte_flow.h > @@ -1392,14 +1392,14 @@ static const struct rte_flow_item_meta rte_flow_item_meta_mask = { > */ > struct rte_flow_item_gtp_psc { > uint8_t pdu_type; /**< PDU type. */ > - uint8_t qfi; /**< QoS flow identifier. */ > + uint8_t qfi; /**< PPP, RQI, QoS flow identifier. */ > }; By design requirement, rte_flow_item_* should start with the relevant protocol header. There is already a deprecation notice for using protocol header directly in the rte_flow_item* [1] and Adrew/Ivan already fixed a few of them [2]. Your patch is not directly related on this, but since you are touching to the flow_item, would you mind create a protocol struct for it first, and use it in the "struct rte_flow_item_gtp_psc"? So the protocol related update can be done in the protocol header, instead of rte_flow struct. [1] https://git.dpdk.org/dpdk/tree/doc/guides/rel_notes/deprecation.rst?h=v21.02#n99 [2] https://git.dpdk.org/next/dpdk-next-net/commit/?id=4a061a7bd70bfa023de23e8e654e