From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 5E19B5589 for ; Thu, 28 Feb 2019 20:21:26 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Feb 2019 11:21:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,424,1544515200"; d="scan'208";a="121600653" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by orsmga008.jf.intel.com with ESMTP; 28 Feb 2019 11:21:24 -0800 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by IRSMSX153.ger.corp.intel.com (163.33.192.75) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 28 Feb 2019 19:21:23 +0000 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.28]) by IRSMSX156.ger.corp.intel.com ([169.254.3.58]) with mapi id 14.03.0415.000; Thu, 28 Feb 2019 19:21:23 +0000 From: "Dumitrescu, Cristian" To: "Sheehan, Georgina" , "dev@dpdk.org" Thread-Topic: [PATCH v2 1/3] librte_pipeline: add support for DSCP action Thread-Index: AQHUwtuuEHtvoWTlJkGcpttoxQembKX1qLIQ Date: Thu, 28 Feb 2019 19:21:23 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891268E846065@IRSMSX108.ger.corp.intel.com> References: <20180211085722.59717-1-georgina.sheehan@intel.com> <20180211132905.7502-1-georgina.sheehan@intel.com> In-Reply-To: <20180211132905.7502-1-georgina.sheehan@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMWY1M2NhYjYtYjRkOC00YTUwLTk3MGQtMGMwNTk5NTBkOTYwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoic2JpVXROWUkrdklCXC9OVTNCUWVUWG9ZMU9oTU9leDh6WWVKdDZGVGJveVRDQVV4ZGZOa280R0RtekVWcFNSTjIifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 1/3] librte_pipeline: add support for DSCP action 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 Feb 2019 19:21:26 -0000 Hi Georgina, Thanks for your patch set and sorry for my delayed reply! > -----Original Message----- > From: Sheehan, Georgina > Sent: Sunday, February 11, 2018 1:29 PM > To: dev@dpdk.org > Cc: Dumitrescu, Cristian ; Sheehan, > Georgina > Subject: [PATCH v2 1/3] librte_pipeline: add support for DSCP action According to DPDK policy, the title of a library patch should remove the "l= ibrte_" prefix from the library name, i.e. the title of this patch should b= e: "pipeline: add support for DSCP action". >=20 > From: Georgina Sheehan >=20 > This allows the application to change the DSCP value of incoming packets >=20 > v2: Added in call of function parse_table_action_dscp in softnic cli file >=20 > Signed-off-by: Georgina Sheehan > --- > lib/librte_pipeline/rte_table_action.c | 133 +++++++++++++++++++++++++ > lib/librte_pipeline/rte_table_action.h | 20 ++++ > 2 files changed, 153 insertions(+) >=20 > diff --git a/lib/librte_pipeline/rte_table_action.h > b/lib/librte_pipeline/rte_table_action.h > index c96061291..28db53303 100644 > --- a/lib/librte_pipeline/rte_table_action.h > +++ b/lib/librte_pipeline/rte_table_action.h > @@ -102,6 +102,9 @@ enum rte_table_action_type { >=20 > /** Packet decapsulations. */ > RTE_TABLE_ACTION_DECAP, > + > + /** Differentiated Services Code Point (DSCP) **/ > + RTE_TABLE_ACTION_DSCP, > }; >=20 > /** Common action configuration (per table action profile). */ > @@ -794,6 +797,23 @@ struct rte_table_action_decap_params { > uint16_t n; > }; >=20 > +/** > + * RTE_TABLE_ACTION_DSCP > + */ > +/** DSCP action configuration (per table action profile). */ > +struct rte_table_action_dscp_config { > + /** dscp length */ > + uint8_t dscp_len; What exactly is DSCP length? > + > +}; > + > +/** DSCP action parameters (per table rule). */ > +struct rte_table_action_dscp_params { > + /** dscp value to be set */ > + uint8_t dscp_val; > + > +}; > + > /** > * Table action profile. > */ > -- > 2.17.1 I have a fundamental issue with this approach for DSCP marking action: 1/ This proposal seems to simply read a single pre-configured DSCP value fr= om the table entry and apply it to all the packets that hit this table entr= y. 2/ To me, this approach is not really useful, as in practice different pack= ets that belong to the same flow can be tagged with different DSCP values o= n the way out: for example, the flow can represent all the traffic for a gi= ven BNG subscriber, which can include management data, voice, real time vid= eo, high priority best effort, low priority best effort, etc packets. DSCP is typically used by a specific provide to tag the traffic class and t= he priority of the incoming packets within its network. Packets from the sa= me user can belong to different traffic classes and drop precedences, such = as described in e.g. RFC 2598 and related. Therefore, what I suggest is: 1/ Replacing the single pre-defined DSCP value per table entry with an arra= y defined per table (not per table entry). 2/ The reason to define this array per table as opposed to table entry is t= hat the DSCP code points are typically defined per network (all users) rath= er than per user. Similar approach is already used by other existing action= s, such as metering and traffic management. 3/ The array is a 2D array indexed by the traffic class (mbuf->hash.sched.t= raffic_class) and color/drop precedence (mbuf->hash.sched.color) of the cur= rent packet (mbuf). The values are DSCP values for different traffic classe= s and packet colors. 4/ The number of traffic classes (n_traffic_classes) should be a configurat= ion parameter for this action, therefore the size of the DSCP array is n_tr= affic_classes x RTE_COLORS. Makes sense? Thanks, Cristian