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 87EEDA00C4; Tue, 26 Apr 2022 14:08:09 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 63D9A40E78; Tue, 26 Apr 2022 14:08:09 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id DC9BE40C35 for ; Tue, 26 Apr 2022 14:08:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650974888; x=1682510888; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bofDajlzy/8QuBq6QLGqdi3CGPtaI7bgRpqkBVk0mEA=; b=aiU9k2dLZlhBcQlo+Dta5uYe9NK1g5KYv9hPCEwH9f4D+kQMlEkRFdjj SGPnEVoe/nTpa8x7wVDaHvuiTDnN/ucCmzNECYVGYuI5KFpe/ebOfZQiT 6ogKU04aYAN/sxfhfV4o8zq73GPtqviapeGDgJbcJldWoQT2T9mjoqK3u GOruOEIwOXNtYwcG5OLs5KyYRQVwT5jvrn2Duji+zYrzM3kzMuk9Nh5+v /PT+btqquodRD8v8MSADylN7uWS5Gj8gK2ii3Kbl6aNUwvLx3t2zEKR24 A2iGnMciIAS38ogARSNCateVPcNry/qO2eLCjplhqqbvDcQVZs4MU4UL8 Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10328"; a="265360860" X-IronPort-AV: E=Sophos;i="5.90,290,1643702400"; d="scan'208";a="265360860" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 05:08:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,290,1643702400"; d="scan'208";a="616966659" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmsmga008.fm.intel.com with ESMTP; 26 Apr 2022 05:08:04 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Tue, 26 Apr 2022 05:08:04 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27 via Frontend Transport; Tue, 26 Apr 2022 05:08:04 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.57.44) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.27; Tue, 26 Apr 2022 05:08:04 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hqH2rRZ8j+fIt3DzmYVsOk4MeXh5P3XMjnC0K00fqE0iwWqA69TQKONRaT9b/aetunioewNOA1UnCjdA2nUTViWqs862wdsaOUJiyP8HvwQOaAE9VKLhp0PsjsefWe2/BUX3NLxv336AssAyXrjvJVjWgYZ41reLnN/m4In25HWKeEvAAJe8HGjLYYlEr+xXezBAv7nMYNNDk7DF9PUS7A8I/fgFPNysUz1KREimPobSyI/hHlo3lcOcbUkNemFcq25xRJaUFjypx4n+rvmYN1teZ6ZacUQkY6SPtWPMiqK5lkW+NYnCzzPYEiGWmIWs2zX1g2emwERmE4bnfYvAyw== 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=R4y8lLO3t5DEewFhLXvf5tGPE/wKnExRHBo5v2Jf2Bw=; b=DdYYb/3H9B5UvK4ayzMMvK0prjQPdzGxsFLcTmSqe7L5yTNP6fCTTSuvUZ+8iXZsWRT28DmsdBa7YZEGSVJL/GmQTHMiKcAyFcmyiTriVd4IQtJcIo8TlIeEbp7X0W3/BCTuDLmrAbXG2mS/WjJQcPBm9b6pYXGzFp1tNKS6PN2tNtJKPLeZsnoSbnmWLYWXmq43mYLQ36nRQ2vfn5/8LBo7JigcNuYDOxo7fKkj+8271uxlIf7ALDzUVF1WHTjnwaOsoK6I8lPbt3uUi0TMblCcIA9+UtFFktlDiApZeNdq+G3xXQO9zb6pMpvSRJJEA4hTq+SXfJcO7EWN38+2PA== 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 Received: from DM8PR11MB5670.namprd11.prod.outlook.com (2603:10b6:8:37::12) by DM4PR11MB6213.namprd11.prod.outlook.com (2603:10b6:8:ae::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5186.15; Tue, 26 Apr 2022 12:08:01 +0000 Received: from DM8PR11MB5670.namprd11.prod.outlook.com ([fe80::5dc9:53d7:3ece:fa2d]) by DM8PR11MB5670.namprd11.prod.outlook.com ([fe80::5dc9:53d7:3ece:fa2d%2]) with mapi id 15.20.5186.021; Tue, 26 Apr 2022 12:08:01 +0000 From: "Dumitrescu, Cristian" To: "jerinj@marvell.com" , "dev@dpdk.org" , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , Ray Kinsella CC: "ajit.khaparde@broadcom.com" , "aboyer@pensando.io" , "Xing, Beilei" , "Richardson, Bruce" , "chas3@att.com" , "Xia, Chenbo" , "Loftus, Ciara" , "dsinghrawat@marvell.com" , "ed.czeck@atomicrules.com" , "evgenys@amazon.com" , "grive@u256.net" , "g.singh@nxp.com" , "zhouguoyang@huawei.com" , "Wang, Haiyue" , "hkalra@marvell.com" , "heinrich.kuhn@corigine.com" , "hemant.agrawal@nxp.com" , "hyonkim@cisco.com" , "igorch@amazon.com" , "irusskikh@marvell.com" , "jgrajcia@cisco.com" , "Singh, Jasvinder" , "jianwang@trustnetic.com" , "jiawenwu@trustnetic.com" , "Wu, Jingjing" , "Daley, John" , "john.miller@atomicrules.com" , "linville@tuxdriver.com" , "Wiles, Keith" , "kirankumark@marvell.com" , "oulijun@huawei.com" , "lironh@marvell.com" , "longli@microsoft.com" , "mw@semihalf.com" , "spinler@cesnet.cz" , "matan@nvidia.com" , "Peters, Matt" , "maxime.coquelin@redhat.com" , "mk@semihalf.com" , "humin29@huawei.com" , "pnalla@marvell.com" , "ndabilpuram@marvell.com" , "Yang, Qiming" , "Zhang, Qi Z" , "radhac@marvell.com" , "rahul.lakkireddy@chelsio.com" , "rmody@marvell.com" , "Xu, Rosen" , "sachin.saxena@oss.nxp.com" , "skoteshwar@marvell.com" , "shshaikh@marvell.com" , "shaibran@amazon.com" , Shepard Siegel , "asomalap@amd.com" , "somnath.kotur@broadcom.com" , "sthemmin@microsoft.com" , "Webster, Steven" , "skori@marvell.com" , "mtetsuyah@gmail.com" , "vburru@marvell.com" , "viacheslavo@nvidia.com" , "Wang, Xiao W" , "cloud.wangxiaoyun@huawei.com" , "yisen.zhuang@huawei.com" , "Wang, Yong" , "xuanziyang2@huawei.com" Subject: RE: [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based input color selection Thread-Topic: [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based input color selection Thread-Index: AQHYVao0OgRvEwBMvU6e+l3r9uBfwq0CFK8Q Date: Tue, 26 Apr 2022 12:08:01 +0000 Message-ID: References: <20220301085824.1041009-1-skori@marvell.com> <20220421180241.514767-1-jerinj@marvell.com> In-Reply-To: <20220421180241.514767-1-jerinj@marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.6.401.20 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a0301b6b-930c-4e97-f386-08da277d693e x-ms-traffictypediagnostic: DM4PR11MB6213:EE_ x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YgBwHD7acDAtnmPKgh579FnwSz0vQWAdWAslpa2eO5leJ3Dhp9c9Viy7ZO+CDRFO69M79hGh6fv2Eg9WRmuBNz2mulLOqInuewQ9hiM3NhkfOEgzUZvuDgdwk9ei3MfJxG7k1PFbw3tZjd9qqsZYChkPMMHdbqrTwNaBgLBSagYMPDDt/S1mt93pAKvZrpRmAs+deRbZGsXZoAqs1Fkj8rzRqPrghkLNh6Zos6faDLtmR5pS+ZSOVJ+ZNp9vi1PzN+IpIJp6PuZOq14LfZkbJ5KgJ3wnrVM0rKYHeKPjz7ktMG2juJwlEdBzQg0G2xhVnt9eIcdiSFE6mdB2VLtn91D/LxaqNQ7zzu+aRHESOTo4oul7QyG1rQ7NtvO7cTyJySDJ09yNYc2Jjzp6m2Dbft/fI1foRVb0ZvLZ39zmOp53adlfRhqq4emW+gb2G8fvr7aA8k2TKg4GyOH6bpXDDGZyF7romHkj7Damzze4RDznuqJrE0NHQsy3o58gJFk/y3TGIXLaWKGe/W+JMj3rs8C5Mz8HMvsbLkxxdUvqG2RqWJ8BGx+YxHGdioPTDwzcjtkdiwcNxj74QZL0I5PCrDS/9+GXWPxAkT8/aw8a3dMc3z3DVIY4mtG4+/R1g1bb7+mhLN8NnybFNeS0zys+Tqzrah6KyMA1gGE6fWUFqjn3BXY6cGvUJPu3vPVm+WzMokW2rAJV3uus6NaCsUyjsw== 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:(13230001)(366004)(52536014)(8936002)(55016003)(71200400001)(9686003)(122000001)(2906002)(30864003)(316002)(26005)(508600001)(33656002)(110136005)(186003)(54906003)(83380400001)(7696005)(38070700005)(38100700002)(4326008)(86362001)(66476007)(64756008)(66556008)(8676002)(5660300002)(66446008)(66946007)(6506007)(82960400001)(7416002)(7406005)(7366002)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?kBtRWj8fy44hAZZwyr3VQ+QWUsRn68xobJ3CLy4CwPwhaSoA85L4Fg1ixq6i?= =?us-ascii?Q?7f+Qm47KP0vkx46wah0DhBoeJ+IThiWZx0lVJlaIC7vgiXPMR+h4H9FILoyo?= =?us-ascii?Q?y/cro4DspGOGIlAwiTsNn/WidmvTpwkcZPoRDzTLgezxzNvhI83UN0fojfTO?= =?us-ascii?Q?a945ibB5yeBKiI41OmzzlfO/Cc+mXx9JKodrV2ZVBer/JZqVSR80Zg8fvoAT?= =?us-ascii?Q?xuNnrukPKS98M/UDXQab8PKEuG7JPAdQoM6NMaWbLQCbp8Z6+ErHeGG2Z5W0?= =?us-ascii?Q?VhUN6hvmORIzsq6udIPG5Ic8maZJNH4awG0AWbSh1P2lJyDcvN4jjKHlcZoS?= =?us-ascii?Q?fN8yKzkxAq/8P6mi6wlJDtzfHwMoT7pYgZfsBIR2DHV3nM50jh2NhZUIZnPK?= =?us-ascii?Q?U6NpDugG6Kfa1q5dvu9Gt1lY5mFXnLv6tRTZDFoEu/EUKaAWblDSt2b+KB7J?= =?us-ascii?Q?oSYeUwD+FC0jystNwjF45zV16cYRwSmaniETGPfC9Moq57sDsPsTijBpGzcd?= =?us-ascii?Q?yh16YVFj6BDQOogSY+ZCgTVLcXeciQRxxGKkm+QdjPuAcx7eiNg4vlxoCr8g?= =?us-ascii?Q?Xjq/TA9EbB9rX2SFRbhvwaJy3vD+Cis2i0fBswRkbt2B2SlTEU+FKWsBhUls?= =?us-ascii?Q?5huAmmZbZkOrIwutx05NlIGSHlzhmxyfIIy4ZoK98YuoWUULwqOvQifEV0pT?= =?us-ascii?Q?oHanS4BoE9Q3EGXX2lhmvuWGsQIXLINk71vbVFTOxJKJWfJ6baILURAtR0QN?= =?us-ascii?Q?axmiH4zhsNDSM5lWCyf2YPHItVkdX2JS5obrLu4HGgNBi1yf10vmsNGgudum?= =?us-ascii?Q?i1GLvf0B4euNjeSmkkmaMwEYY/cGJao0BvL4cWXFqWyO6qYPXOKSMRIynEUB?= =?us-ascii?Q?iC+kTVi4ksKtFzY38rQjkrbWESXSrUbpo83q4NFtYosesArLQ/ZKOceJ/YXM?= =?us-ascii?Q?ySkw+IYhxeEqNq4RtzjIgK8aMSX+qmQmBwVWb2uO0vgqUgCBPLmpiDefhAmD?= =?us-ascii?Q?d90MURhgj7bHDBiDpWaAWOHE8o7fIdclPqddg1jkqlucpT+Ohocy/Pe30BNb?= =?us-ascii?Q?qmWcQvyxj12FEVic76oQWZ8S/ko3CN7U/onvilDLuQqoXDI+Ef5sQGXKR+JS?= =?us-ascii?Q?4eiXAVDFWo8Ffl8OvnYZLgjZFoAhnDdcHfLievdiILEbTNXLJtua5QWiLRB9?= =?us-ascii?Q?K4+rCbPZJQNyFhleiTyLTWvmHEwBhnhiuFeifEeFyMPRiyTBPY7RmfUu5WIF?= =?us-ascii?Q?xzX2DPDOBZEDiHrgNrLyz+9bP9FO6juD3nM8HDmmwMal9eLVT5Evp1YpX3Sz?= =?us-ascii?Q?XXI4DFHs0ubkvST/0QBoKlMuo6Lnqpz3iz+T6r5QpiI9AKW3SjaLmT9oP9Ho?= =?us-ascii?Q?AKVbHPWvTAIf8f39GVSbPMuJuprTcQAY2w3Ve5Ld9OidQYOJWcd+lfvg/uud?= =?us-ascii?Q?qA8fbNVKI35zj8+7OfldhngkjUHcCt5BVPrneQd35W6jwJ2XDL4WDwHTz6zV?= =?us-ascii?Q?UFk1/fLUWgPAYXzda9XKwlGNBNlprWT43SmWIXF3DkEQ2k+cipHdsGLGg0is?= =?us-ascii?Q?wMYHTMtARAceXEcaEjJKVPshhM86pJemxOk9d/FZcTC0ZT+DfZanbeujp6hc?= =?us-ascii?Q?A7wmm75D/nKJVtQu+SWbWBiHoVyuupb3oG7TFiGsEuGjvEbNnj5tmf3KbmfX?= =?us-ascii?Q?2r4pUEJDhw93Y0ZRsydxc4q/+fzC6HbxAPllDP8XeOeVrw723GyztHHmwQe7?= =?us-ascii?Q?8OnTVjDhR+fNRnHCHc0+YpIJjySaUho=3D?= 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: a0301b6b-930c-4e97-f386-08da277d693e X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2022 12:08:01.6318 (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: GickhZmkN+jyl6Fs5kGRbxuJKE3ZW2lyOXAOqZk5FZ5lMVKW9JKk/QqThN9Cpis8N/WwHTkyKA0oRYsa1njSAv+ecPP/4rU+ZLIb2FhQGS0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6213 X-OriginatorOrg: intel.com 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 Hi Jerin, Thank you for implementing according to our agreement, I am happy to see th= at we are converging. Here are some comments below: > diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h > index 40df0888c8..76ffbcf724 100644 > --- a/lib/ethdev/rte_mtr.h > +++ b/lib/ethdev/rte_mtr.h > @@ -213,6 +213,52 @@ struct rte_mtr_meter_policy_params { > const struct rte_flow_action *actions[RTE_COLORS]; > }; >=20 > +/** > + * Input color protocol method I suggest adding some more explanations here: More than one method can be enabled for a given meter. Even if enabled, a m= ethod might not be applicable to each input packet, in case the associated = protocol header is not present in the packet. The highest priority method t= hat is both enabled for the meter and also applicable for the current input= packet wins; if none is both enabled and applicable, the default input col= or is used. @see function rte_mtr_color_in_protocol_priority_set() > + */ > +enum rte_mtr_color_in_protocol { > + /** > + * If the input packet has at least one VLAN label, its input color is > + * detected by the outermost VLAN DEI(1bit), PCP(3 bits) > + * indexing into the struct rte_mtr_params::vlan_table. > + * Otherwise, the *default_input_color* is applied. > + * The statement "Otherwise, the *default_input_color* is applied" is incorrec= t IMO and should be removed, as multiple methods might be enabled and also = applicable to a specific input packet, in which case the highest priority m= ethod wins, as opposed to the default input color. I suggest a simplification "Enable the detection of the packet input color = based on the outermost VLAN header fields DEI (1 bit) and PCP (3 bits). The= se fields are used as index into the VLAN table" > + * @see struct rte_mtr_params::default_input_color > + * @see struct rte_mtr_params::vlan_table > + */ > + RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN =3D RTE_BIT64(0), > + /** > + * If the input packet has at least one VLAN label, its input color is > + * detected by the innermost VLAN DEI(1bit), PCP(3 bits) > + * indexing into the struct rte_mtr_params::vlan_table. > + * Otherwise, the *default_input_color* is applied. > + * > + * @see struct rte_mtr_params::default_input_color > + * @see struct rte_mtr_params::vlan_table > + */ Same simplification suggested here. > + RTE_MTR_COLOR_IN_PROTO_INNER_VLAN =3D RTE_BIT64(1), > + /** > + * If the input packet is IPv4 or IPv6, its input color is detected by > + * the outermost DSCP field indexing into the > + * struct rte_mtr_params::dscp_table. > + * Otherwise, the *default_input_color* is applied. > + * > + * @see struct rte_mtr_params::default_input_color > + * @see struct rte_mtr_params::dscp_table > + */ Same simplification suggested here. > + RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP =3D RTE_BIT64(2), I am OK to keep DSCP for the name of the table instead of renaming the tabl= e, as you suggested, but this method name should reflect the protocol, not = the field: RTE_MTR_COLOR_IN_PROTO_OUTER_IP. > + /** > + * If the input packet is IPv4 or IPv6, its input color is detected by > + * the innermost DSCP field indexing into the > + * struct rte_mtr_params::dscp_table. > + * Otherwise, the *default_input_color* is applied. > + * > + * @see struct rte_mtr_params::default_input_color > + * @see struct rte_mtr_params::dscp_table > + */ Same simplification suggested here. > + RTE_MTR_COLOR_IN_PROTO_INNER_DSCP =3D RTE_BIT64(3), I am OK to keep DSCP for the name of the table instead of renaming the tabl= e, as you suggested, but this method name should reflect the protocol, not = the field: RTE_MTR_COLOR_IN_PROTO_INNER_IP. > + > /** > * Parameters for each traffic metering & policing object > * > @@ -233,20 +279,58 @@ struct rte_mtr_params { > */ > int use_prev_mtr_color; >=20 > - /** Meter input color. When non-NULL: it points to a pre-allocated and > + /** Meter input color based on IP DSCP protocol field. > + * > + * Valid when *input_color_proto_mask* set to any of the following > + * RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP, > + * RTE_MTR_COLOR_IN_PROTO_INNER_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. > + * Point (DSCP) input packet field. > + * > + * When NULL: it is equivalent to setting this parameter to an all-gree= n > + * 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 enum > rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP > + * @see enum > rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_DSCP > + * @see struct rte_mtr_params::input_color_proto_mask > */ > enum rte_color *dscp_table; > - > + /** Meter input color based on VLAN DEI(1bit), PCP(3 bits) protocol > + * fields. > + * > + * Valid when *input_color_proto_mask* set to any of the following > + * RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN, > + * RTE_MTR_COLOR_IN_PROTO_INNER_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 enum > rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN > + * @see enum > rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_VLAN > + * @see struct rte_mtr_params::input_color_proto_mask > + */ > + 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 +345,25 @@ struct rte_mtr_params { >=20 > /** Meter policy ID. @see rte_mtr_meter_policy_add() */ > uint32_t meter_policy_id; > + > + /** Set of input color protocols to be enabled. > + * > + * Set value to zero to configure as color blind mode. > + * > + * When multiple bits set then rte_mtr_color_in_protocol_priority_set() > + * shall be used to set the priority, in the order, in which protocol > + * to be used to find the inpput color. > + * > + * @see enum rte_mtr_color_in_protocol > + * @see rte_mtr_color_in_protocol_priority_set() > + */ > + uint64_t input_color_proto_mask; We should not have this as an input parameter at all, please remove this fi= eld. This mask is implicitly created by the user by calling the rte_mtr_col= or_in_protocol_priority_set() API function. If this function is called for = a given method, then that method is enabled with the given priority; when t= his function is not called for a given method, then that method is disabled= . > + > + /** Input color to be set for the input packet when none of the > + * enabled input color methods is applicable to the input packet. > + * Ignored when this when *input_color_proto_mask* set to zero. > + */ > + enum rte_color default_input_color; > }; >=20 > /** > @@ -417,6 +520,16 @@ struct rte_mtr_capabilities { > * @see enum rte_mtr_stats_type > */ > uint64_t stats_mask; > + > + /** Set of supported input color protocol. > + * @see enum rte_mtr_color_in_protocol > + */ > + uint64_t input_color_proto_mask; Agree. > + > + /** When non-zero, it indicates that driver supports separate > + * input color table for given ethdev port. > + */ > + int separate_input_color_table_per_port; The input color tables are actually configured per meter object, do we also= need a "separate_input_color_table_per_meter" capability flag? > }; >=20 > /** > @@ -832,6 +945,59 @@ 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); > +/** > + * Set the priority for input color protocol > + * > + * When multiple bits set in struct rte_mtr_params::input_color_proto_ma= sk > + * then this API shall be used to set the priority, in the order, in > + * which protocol to be used to find the input color. As stated above, we should remove struct rte_mtr_params::input_color_proto_= mask, as it is build implicitly by calling this function. I suggest reiterating the explanation from above: More than one method can be enabled for a given meter. Even if enabled, a m= ethod might not be applicable to each input packet, in case the associated = protocol header is not present in the packet. The highest priority method t= hat is both enabled for the meter and also applicable for the current input= packet wins; if none is both enabled and applicable, the default input col= or is used. @see function rte_mtr_color_in_protocol_priority_set() > + * > + * @param[in] port_id > + * The port identifier of the Ethernet device. > + * @param[in] mtr_id > + * MTR object ID. Needs to be valid. > + * @param[in] proto > + * Input color protocol to apply priority. > + * MTR object's *input_color_proto_mask* should be configured > + * with proto value. > + * @param[in] priority > + * Input color protocol priority. Value zero indicates > + * the highest priority. Agree. > + * @param[out] error > + * Error details. Filled in only on error, when not NULL. > + * @return > + * 0 on success, non-zero error code otherwise. > + * > + * @see rte_mtr_params::input_color_proto_mask > + */ > +__rte_experimental > +int > +rte_mtr_color_in_protocol_priority_set(uint16_t port_id, uint32_t mtr_id= , > + enum rte_mtr_color_in_protocol proto, uint32_t priority, > + struct rte_mtr_error *error); > /** > * MTR object enabled statistics counters update > * Regards, Cristian