From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8A130A034F; Mon, 11 Oct 2021 17:23:55 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 21995410DF; Mon, 11 Oct 2021 17:23:55 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id 3BCF04003C for ; Mon, 11 Oct 2021 17:23:52 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10134"; a="225668399" X-IronPort-AV: E=Sophos;i="5.85,364,1624345200"; d="scan'208";a="225668399" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Oct 2021 08:14:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,364,1624345200"; d="scan'208";a="547061401" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga004.fm.intel.com with ESMTP; 11 Oct 2021 08:14:40 -0700 Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Mon, 11 Oct 2021 08:14:39 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Mon, 11 Oct 2021 08:14:39 -0700 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (104.47.73.175) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Mon, 11 Oct 2021 08:14:39 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jebKeJnkoUSEN/IxEav4agmFGb23i54zFHLsy7HuA+IbLELvVeaobwbwm35qNK+GLNXpI5u333t5ITIk5QHVxvWDMIu5wfXjkhqAySnM/jByxWp6/VK7Y2NPwc5Hg02HDj2B6vbA0RCLseKGSoogax4VgMeKE1bDR3/U5S3WStBJD9wSd9eL7Do9K70JQWlUnC5kyCGw8pAdinXgKyuHYIScFvGsviMY4j2MCMQ9D71r+HIUSpxzPfavUQQBiJbOV8TV4ATONVqJSwlS86GVAqPgxvQdzvKfIAMfM5JW/skGOSJsYvGdhHmlq0lGi9cMqfguC9D8eBMkg87oKJs1fQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5uzs/+y/g6/om6n5//1WeM2D3dOPxZ9Rvca0uY29SRc=; b=ZOS3WLcbj/sQs56G35wzjlwIsPIARC9bCX+Y+bwO5iwKXShWVsdZd/Nt6APw4J1dXi8fm80YIP+jvB5qLZaxaZg8p39RlMSPwbpdrASEfh1VV1ywnbcd7uMJ0dX40AMK4uQpPo4OdGPF86V7uN6if/YxzdEKyJOVRr7OYPV1Z9JIYhMrSM5bdDfKEgIoU4For5Z/1ShIFPfk1f8VYN4n0n7V3fMSL7dEVnAIH91XjxmG8tQqXKh+B3BxQBgsOpMKoc4xQ7cmUXs1Gd7uf30cEz2spA9UlEV7F98oKABJVyiKmjudCDhlN0UYGA4twG62NIyFX6Fr3mjg2Q7qO3N0jA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5uzs/+y/g6/om6n5//1WeM2D3dOPxZ9Rvca0uY29SRc=; b=ZuPyEnCgpnV0YX8f/8DtE1hD0EleHFQgcfSJnmtAo+685zFNCR2OWl76gueV4cSBoyTyRu7rjC7g2+nJF5gJ7wKx6aYaJsPMeu3MshbMK1crdRid6h5UeonvhbeAttvZChwHvmwBCrqas2iiygom1OmZQdw3r++V96fAb7oVfAs= Received: from DM8PR11MB5670.namprd11.prod.outlook.com (2603:10b6:8:37::12) by DM8PR11MB5605.namprd11.prod.outlook.com (2603:10b6:8:26::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Mon, 11 Oct 2021 15:14:38 +0000 Received: from DM8PR11MB5670.namprd11.prod.outlook.com ([fe80::c0f1:1135:ceb5:ac10]) by DM8PR11MB5670.namprd11.prod.outlook.com ([fe80::c0f1:1135:ceb5:ac10%8]) with mapi id 15.20.4587.026; Mon, 11 Oct 2021 15:14:38 +0000 From: "Dumitrescu, Cristian" To: "jerinj@marvell.com" , Thomas Monjalon , "Yigit, Ferruh" , "Andrew Rybchenko" CC: "dev@dpdk.org" , "arybchenko@solarflare.com" , "lizh@nvidia.com" , "ajit.khaparde@broadcom.com" , "Singh, Jasvinder" , "matan@nvidia.com" , "ndabilpuram@marvell.com" , "skori@marvell.com" , "rkudurumalla@marvell.com" Thread-Topic: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features Thread-Index: AQHXlZ0GSf3CJy5KdEC2BO1TmbpJ/6vOLc6Q Date: Mon, 11 Oct 2021 15:14:38 +0000 Message-ID: References: <20210820082401.3778736-1-jerinj@marvell.com> In-Reply-To: <20210820082401.3778736-1-jerinj@marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.6.200.16 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: marvell.com; dkim=none (message not signed) header.d=none;marvell.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 921eeeae-3c84-4413-0362-08d98cc9d7ce x-ms-traffictypediagnostic: DM8PR11MB5605: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mul/rJDFMAc3H5H1gd3EkzigneerqVwgVOORyGO2A5gvMNjvBis/9k3kCVwJCapkMPADBAANfRP3TxHoh7d8OJMRKk4yMKTOL8NxxYdRa83mwiUhgfLKDl6WeHYdmd7k9Rkp3u4TUjukArppval19UOpiLtfKLIOa7wl3Tazuya4zHcuEMGrf84GAuQwAofshApK+6fOgzv/vSZ0p7IeYAa65wdZSuQyZj2j1FbSZ9Nx4T828LZlhNAIqofm0r+uMyE0FgmONVqcJIcGipEKUVSMQBuE88HZbXunx7a9xk/2scrRXB+8qOh/CupH7wytnDMBRagU8rWCqy/13BlG+SWykGALBIFQJ9QtkJoR7bT34BhTpiK3UHFs9+ZKANb7AUu6Bmr3xDC6q3IGpAQcFUpApjF8aNXh+A9FUFk+ilIY9jgwDxJiAHKyVyZfpI/pYjFB0nOQHuqhE+cS2xAD20aDEe+uJf9Gli0PZ0AJ2VrK7uatlAGPY1fSQKfSLaMVQxQg3vCmujKkL+Jx4iW93xfwyt79KBBF+uKvkmlissjd/NPJEOfziKj27Biq15rx/pthi2V1awZse6j2BqNdL4pv1eQdi7B6BkujBUII0k7JgkPGZHFqNufYJHgwLRFQVIGZnySAX8DGDDTnJKGvKs8I5Trl1QGUxw+kptdMF34hG/wKJCP/swpOPNnH79im/N+xeVEbuQJajC5AOiqzBw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8PR11MB5670.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(7416002)(6506007)(26005)(33656002)(8936002)(5660300002)(52536014)(54906003)(110136005)(316002)(2906002)(8676002)(4326008)(186003)(53546011)(508600001)(7696005)(83380400001)(55016002)(9686003)(71200400001)(86362001)(66446008)(64756008)(76116006)(66946007)(66556008)(66476007)(38100700002)(38070700005)(122000001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?4pkerYQl04OnXyvL+O/zyI1N0Qab1RvElGFc7z7/w6qWw+plMrO5U+BncqYH?= =?us-ascii?Q?qJcjoNAktYB1oEF7stWaHkFjxtJRmfSsuRISXfZndQnBN8tusn5iaw/DTbKz?= =?us-ascii?Q?nDkFgQ1/OXFkyiUz50dMC/7mUKOsiOPW34y/UpOojSdApQKCWmWRLGz7d2gF?= =?us-ascii?Q?IloQinm69b1MqpailAH4kVWQuhNyLR1DH+8XWvL2Pc8X1fyszXJfCMO4VsME?= =?us-ascii?Q?Kzaoh7nnF3aj7qPPUsrGgygm51mmgy4XFT0Ym2Z3EeYsntIeYK3jg5P56eHy?= =?us-ascii?Q?M8e9yOIYoL4ZjGY3vYH+T2W90qoECQ0NlXkmGABELPh5wt/STR7AIw6GgGNx?= =?us-ascii?Q?s5WoGJdNR+IMxXUIrqDEWs1zbVI5EczCbxyVYNZjH5tH7hVPx39m9nnKWxXq?= =?us-ascii?Q?Zi/KEF58wyHYv7NBCafqnq1wsHsFP2ArodVQYG/+QziyR9scZvTOEoSuxuhW?= =?us-ascii?Q?HMLTbiBOArAJbad4rKCpix1KJeP67Q49tSDfywa9SurJBAEoIMA5tgnRIvzI?= =?us-ascii?Q?J5wXU7YAi/T2NwS1r2h3ihvGkUn+y1KCwF03KM3UiOkDptZ6gY0+chAPGDCP?= =?us-ascii?Q?2wwkqXq0MZvQ/UvltWpN7htfVBnI+zdP9W+gfwff/xgTP06FQl5iFUy86/mw?= =?us-ascii?Q?VttabgdfBihEOpsB+UejuvqTtrz3AQtVEa8geQR2DEuaqFz5CnjL0Batkl2I?= =?us-ascii?Q?TYd4jVK4vqujMzk76MTIuSHlsySjM0pmI2uZLTTXrVzrlkjtl7Wxck4EgsC/?= =?us-ascii?Q?25k0R3/G1UxEYUXbHCnYoUHzyBtSkvIXBhUzx0ojVcNzK4A7R7ZRAf8FnYWB?= =?us-ascii?Q?23a7DbZqfJExn87Xg5oqsMfUEIftqOZsnGD0ij3iWFFor+h3qHeN9D6z9S1G?= =?us-ascii?Q?h2Z807KygExp1b85LHs+s4NEArvv8DNJKBqg+JCnSrnnMKRtwSsgH2/02ttC?= =?us-ascii?Q?XB1sghrnh2MW/4Nq0p1U6yArqCXU5tettQvcgH29ahjatBotZjYRk+LWFbPs?= =?us-ascii?Q?irb7VMrWgSGWpLy4OPb8T/Kc/1/wA3hucXAjd/uIczpRjfnjsia27bB2c+Fk?= =?us-ascii?Q?RoeqQDhkB591out0U6Gk8fMnKbFFuwQMVEIQf3Uwh9QKsAYmW6/j6IW88TYN?= =?us-ascii?Q?uBtj78jtyT1qzunLJtSxVj8G91MY/hdleDfPcplIaqAJ2zsGLVAR2e50EAQ6?= =?us-ascii?Q?X94OLHTm+WTt6y7cJ7aSwNBB4oYqsa2tlNk4YL6OStb7nGOExrFO05jy+XLE?= =?us-ascii?Q?SJbUZE+cLJcCn4Fh4sK/FCCqKGki6qbhPgJbyyMrjZc2VBbydxU2WfuiBM5G?= =?us-ascii?Q?021yHpR6REkhPZhop+dOmCQb?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8PR11MB5670.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 921eeeae-3c84-4413-0362-08d98cc9d7ce X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2021 15:14:38.5050 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1W5MSPAwDxnncC9mpNGPvNTOOLjpQDZhxiPrUJfWyUvM4TRyMfF08v1Mjh2z984Br658BGwF/tksq8Sg16tOgJsg1nPik0JBpBnP2e19WcQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR11MB5605 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features 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" Hi Jerin, > -----Original Message----- > From: jerinj@marvell.com > Sent: Friday, August 20, 2021 9:24 AM > To: Dumitrescu, Cristian ; Thomas Monjalon > ; Yigit, Ferruh ; Andrew > Rybchenko > Cc: dev@dpdk.org; arybchenko@solarflare.com; lizh@nvidia.com; > ajit.khaparde@broadcom.com; Singh, Jasvinder > ; matan@nvidia.com; > ndabilpuram@marvell.com; skori@marvell.com; rkudurumalla@marvell.com; > Jerin Jacob > Subject: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table > features >=20 > From: Jerin Jacob >=20 > Currently, meter object supports only DSCP based on input color table, > The patch enhance that to support VLAN based input color table, > color table based on inner field for the tunnel use case, and support > for fallback color per meter if packet based on a different field. >=20 > All of the above features are exposed through capability and added > additional capability to specify the implementation supports > more than one input color table per ethdev port. >=20 > Signed-off-by: Jerin Jacob > --- > lib/ethdev/rte_mtr.h | 130 > ++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 116 insertions(+), 14 deletions(-) >=20 > diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h > index dc246dd7af..311e8754de 100644 > --- a/lib/ethdev/rte_mtr.h > +++ b/lib/ethdev/rte_mtr.h > @@ -213,6 +213,16 @@ struct rte_mtr_meter_policy_params { > const struct rte_flow_action *actions[RTE_COLORS]; > }; >=20 > +/** > + * Input color table > + */ > +enum rte_mtr_input_color_tbl { > + /** DSCP based input color table */ > + RTE_MTR_INPUT_COLOR_TBL_DSCP, > + /** VLAN based input color table */ > + RTE_MTR_INPUT_COLOR_TBL_VLAN, > +}; > + > /** > * Parameters for each traffic metering & policing object > * > @@ -233,20 +243,44 @@ struct rte_mtr_params { > */ > int use_prev_mtr_color; >=20 > - /** Meter input color. When non-NULL: it points to a pre-allocated > and > - * pre-populated table with exactly 64 elements providing the input > - * color for each value of the IPv4/IPv6 Differentiated Services Code > - * Point (DSCP) input packet field. When NULL: it is equivalent to > - * setting this parameter to an all-green populated table (i.e. table > - * with all the 64 elements set to green color). The color blind mode > - * is configured by setting *use_prev_mtr_color* to 0 and > *dscp_table* > - * to either NULL or to an all-green populated table. When > - * *use_prev_mtr_color* is non-zero value or when *dscp_table* > contains > - * at least one yellow or red color element, then the color aware > mode > - * is configured. > - */ > - enum rte_color *dscp_table; > - > + RTE_STD_C11 > + union { > + /** Meter input color based on DSCP. > + * Valid when rte_mtr_input_color_tbl::tbl_selector is > + * set to RTE_MTR_INPUT_COLOR_TBL_DSCP. > + * When non-NULL: it points to a pre-allocated and pre- > populated > + * table with exactly 64 elements providing the input color for > + * each value of the IPv4/IPv6 Differentiated Services Code > + * Point (DSCP) input packet field. When NULL: > + * it is equivalent to setting this parameter to an all-green > + * populated table (i.e. table with > + * all the 64 elements set to green color). The color blind > mode > + * is configured by setting *use_prev_mtr_color* to 0 and > + * *dscp_table* to either NULL or to an all-green > + * populated table. When *use_prev_mtr_color* is non-zero > value > + * or when *dscp_table* contains at least one yellow or > + * red color element, then the color aware mode is > configured. > + * @see struct > rte_mtr_capabilities::input_color_dscp_supported > + */ > + enum rte_color *dscp_table; > + /** Meter input color based on VLAN. > + * Valid when rte_mtr_input_color_tbl::tbl_selector is > + * set to RTE_MTR_INPUT_COLOR_TBL_VLAN. > + * When non-NULL: it points to a pre-allocated and pre- > populated > + * table with exactly 16 elements providing the input color for > + * each value of the DEI(1bit), PCP(3 bits) input packet field. > + * When NULL: it is equivalent to setting this parameter to an > + * all-green populated table (i.e. table with > + * all the 16 elements set to green color). The color blind > mode > + * is configured by setting *use_prev_mtr_color* to 0 and > + * *vlan_table* to either NULL or to an all-green > + * populated table. When *use_prev_mtr_color* is non-zero > value > + * or when *vlan_table* contains at least one yellow or > + * red color element, then the color aware mode is > configured. > + * @see struct > rte_mtr_capabilities::input_color_vlan_supported > + */ > + enum rte_color *vlan_table; > + }; > /** Non-zero to enable the meter, zero to disable the meter at the > time > * of MTR object creation. Ignored when the meter profile indicated > by > * *meter_profile_id* is set to NONE. > @@ -261,6 +295,25 @@ struct rte_mtr_params { >=20 > /** Meter policy ID. */ > uint32_t meter_policy_id; > + > + /** Select the input color table > + * @see struct rte_mtr_params::dscp_table > + * @see struct rte_mtr_capabilities::input_color_dscp_supported > + * @see struct rte_mtr_params::vlan_table > + * @see struct rte_mtr_capabilities::input_color_vlan_supported > + */ > + enum rte_mtr_input_color_tbl tbl_selector; > + /** Fallback input color for the meter, > + * when *use_prev_mtr_color* set to zero value and > + * when packet is not based on selected *tbl_selector*. > + * @see struct rte_mtr_capabilities::input_color_fallback_supported > + */ > + enum rte_color fallback_input_color; > + /** Input color table based on inner field of selected > + * of *tbl_selector*. > + * @see struct rte_mtr_capabilities::input_color_inner_supported > + */ > + int input_color_inner_enable; > }; >=20 > /** > @@ -417,6 +470,31 @@ struct rte_mtr_capabilities { > * @see enum rte_mtr_stats_type > */ > uint64_t stats_mask; > + > + /** Input color based on DSCP. > + * When non-zero, it indicates that driver supports input color table > + * based on DSCP. > + */ > + int input_color_dscp_supported; > + /** Input color based on VLAN. > + * When non-zero, it indicates that driver supports input color table > + * based on VLAN. > + */ > + int input_color_vlan_supported; > + /** Input color fallback support. > + * When non-zero, it indicates that driver supports input color > + * fallback. > + */ > + int input_color_fallback_supported; > + /** Input color based on inner packet field. > + * When non-zero, it indicates that driver supports input color > + * based on inner field. > + */ > + int input_color_inner_supported; > + /** When non-zero, it indicates that driver supports separate > + * input color table for given ethdev port. > + */ > + int seperate_input_color_table_per_port; > }; >=20 > /** > @@ -832,6 +910,30 @@ rte_mtr_meter_dscp_table_update(uint16_t > port_id, > enum rte_color *dscp_table, > struct rte_mtr_error *error); >=20 > +/** > + * MTR object VLAN table update > + * > + * @param[in] port_id > + * The port identifier of the Ethernet device. > + * @param[in] mtr_id > + * MTR object ID. Needs to be valid. > + * @param[in] vlan_table > + * When non-NULL: it points to a pre-allocated and pre-populated table > with > + * exactly 16 elements providing the input color for each value of the > + * each value of the DEI(1bit), PCP(3 bits) input packet field. > + * When NULL: it is equivalent to setting this parameter to an "all-gr= een" > + * populated table (i.e. table with all the 16 elements set to green c= olor). > + * @param[out] error > + * Error details. Filled in only on error, when not NULL. > + * @return > + * 0 on success, non-zero error code otherwise. > + */ > +__rte_experimental > +int > +rte_mtr_meter_vlan_table_update(uint16_t port_id, > + uint32_t mtr_id, > + enum rte_color *vlan_table, > + struct rte_mtr_error *error); > /** > * MTR object enabled statistics counters update > * > -- > 2.33.0 Allowing the configuration of the packet input color based on multiple prot= ocols as opposed to just IP DSCP field makes sense to me. A few questions/suggestions: 1. How do we decide which field/protocol takes precedence to define the pac= ket input color? You are enabling 2 possible options so far, i.e. VLAN tag = PCP field and IP DSCP field, which one is to be set for the current meter o= bject? Using the capabilities to decide is confusing, as a specific meter = object might be able to support multiple or even all the possible options (= e.g. the meter object is fine with either IP DSCP or VLAN PCP). Therefore, = we need a clear mechanism to unequivocally pick one; I think the user must= explicitly define which input color methodology is to be used by explicitl= y setting a field (to be added) in the meter object parameter structure. 2. What if the defined input color methodology is not applicable to the cur= rent input packet? For example, the user selects VLAN PCP, but some or all = of the input packets do not contain any VLAN labels? 3. How do we manage the many packet fields that could be used as the key fo= r the input color: outer IP DSCP, inner IP DSCP, VLAN 1st label, VLAN 2nd l= abel, MPLS QoS, etc? - Approach A: Use an enumeration, like you propose, and we can add more in = the future. Not ideal. - Approach B: Point to a protocol-agnostic packet field by defining the off= set and mask of a 64-bit field. Advantage: we don't need to change the API = every time we add a new option. 4. I suggest we use a unified input color table as opposed to one per proto= col, i.e. rename the struct rte_mtr_params::dscp_table to color_in_table. T= he size of this table could be implicitly defined by the packet field type = (in case of enum) or the field mask (in case of protocol-agnostic field off= set and mask), as described above. Regards, Cristian