From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id D57D37D0E for ; Mon, 4 Sep 2017 16:32:24 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga105.fm.intel.com with ESMTP; 04 Sep 2017 07:32:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,475,1498546800"; d="scan'208";a="1191381802" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga001.fm.intel.com with ESMTP; 04 Sep 2017 07:32:22 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.167]) by IRSMSX101.ger.corp.intel.com ([169.254.1.22]) with mapi id 14.03.0319.002; Mon, 4 Sep 2017 15:32:21 +0100 From: "Dumitrescu, Cristian" To: Hemant Agrawal , "dev@dpdk.org" CC: "thomas@monjalon.net" , "adrien.mazarguil@6wind.com" , "jerin.jacob@caviumnetworks.com" Thread-Topic: [PATCH 2/3] ethdev: add new rte_mtr API for traffic metering and policing Thread-Index: AQHTIvnMqS+xvdf9Q0eeWxqGMLJLVqKkzByg Date: Mon, 4 Sep 2017 14:32:21 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891267BAB2088@IRSMSX108.ger.corp.intel.com> References: <1496162653-137817-3-git-send-email-cristian.dumitrescu@intel.com> <1503705973-80742-1-git-send-email-cristian.dumitrescu@intel.com> <1503705973-80742-3-git-send-email-cristian.dumitrescu@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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 2/3] ethdev: add new rte_mtr API for traffic metering and policing 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: Mon, 04 Sep 2017 14:32:25 -0000 Hi Hemant, Thanks very much for your input! ... > > + > > +/** > > + * Traffic metering algorithms > > + */ > > +enum rte_mtr_algorithm { > > + /**< Single Rate Three Color Marker (srTCM) - IETF RFC 2697. */ > > + RTE_MTR_SRTCM_RFC2697 =3D 0, > > + > > + /**< Two Rate Three Color Marker (trTCM) - IETF RFC 2698. */ > > + RTE_MTR_TRTCM_RFC2698, >=20 > will you please also add following here > 1. RFC-4115-A differentiated service two-rate three-color marker with > efficient handling of in-profile traffic > 2. Pass Through Mode- This mode does not implement differentiated > services. It can be used for some applications to block/pass selected > flows and set a constant color for these flows. The default (disabled) > mode is color-aware pass-through with no dropping of packets. > - In color-aware mode, packet pre-color is copied to the packet color > - In color-blind mode, the default color is programmable per profile > - Configurable next module and command per packet color. Each color > action can be programmed to pass or drop the packet. >=20 Yes, will add both. The trTCM from RFC 4115 was already on my list, adding = the pass-through mode makes sense to me as well. ... > > +/** > > + * Meter profile delete > > + * > > + * Delete an existing meter profile. This operation fails when there i= s > > + * currently at least one user (i.e. MTR object) of this profile. > > + * >=20 > Do you want to do this checking at library level or at driver level? > Same profile can be used by two distinct drivers! >=20 > This is applicable for other APIs as well. Your current API > implementation is mostly pass-through. A stateful will be better. >=20 Yes, the same meter profiles can potentially be shared for a group of ethde= v ports, but unfortunately we cannot do this with the current ethdev API, w= hich is per port with no sharing ability between groups of ports. Here we are lucky to have just a read-only configuration template that need= s to be shared amongst ports, so the quick workaround is to define the same= profile for each port at the expense of some (small) work duplication. Hop= efully this is OK with you? ... Regards, Cristian