From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0081.outbound.protection.outlook.com [104.47.0.81]) by dpdk.org (Postfix) with ESMTP id CC5641E2B for ; Mon, 20 Aug 2018 15:17:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wccKj51FDxAuk6MSqgh9QfRkE80vfIBp5ZTZSo2AY/U=; b=jRqhtZY+gOObR3eFARBRJqydXvteg3rt411wXyh248n/ZOmOvzif2XSLk8iUBWYNw7Dje5iZb6T1EYimXnLi7wpGe/crpBALvtx/tL5zv2YqxHz8G1A0fMKj4m5e++NogP7fDo8pgnQ+cvio12NNgtRu2CGR71QJvFs+uAmOdgg= Received: from AM4PR05MB3265.eurprd05.prod.outlook.com (10.171.186.150) by AM4PR05MB1683.eurprd05.prod.outlook.com (10.165.245.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1059.20; Mon, 20 Aug 2018 13:17:25 +0000 Received: from AM4PR05MB3265.eurprd05.prod.outlook.com ([fe80::a9a6:92c9:e3aa:9436]) by AM4PR05MB3265.eurprd05.prod.outlook.com ([fe80::a9a6:92c9:e3aa:9436%5]) with mapi id 15.20.1059.023; Mon, 20 Aug 2018 13:17:25 +0000 From: Slava Ovsiienko To: "dev@dpdk.org" , Adrien Mazarguil , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko CC: Shahaf Shuler , Ori Kam Thread-Topic: [RFC] ethdev: flow counters batch query Thread-Index: AQHUOHp937PgCH4RU0msj974Z53mfaTInF/g Date: Mon, 20 Aug 2018 13:17:25 +0000 Message-ID: References: <1534765161-12321-1-git-send-email-viacheslavo@mellanox.com> In-Reply-To: <1534765161-12321-1-git-send-email-viacheslavo@mellanox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=viacheslavo@mellanox.com; x-originating-ip: [95.67.35.250] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR05MB1683; 6:a1O/zCl8e0uAZVbExZuw5araf3eQ8ipDii2LxwqhIrvEVfCxh0d3n00Kd1sL+WEt9ZobW3+YvbtxG+ds5snaEdZ4a5L3/0ZpBaWN8xJNkoyWIl55FdpqFUbsNSsSMIeqzXHJ78VvTuRemFuZk827vbbhf+v2xeOC8/BWyOQTpfkngGppwUty/871w1erBVHmhH1hMHShO8C4IibsPcfOOUjcRiYOMEi380p2y5TDdJgJtZ31tVsAUkVFOj9NTfVHg15M1icAndSndJhGP5KtHoWlAPbFYH4dWuvsLJKf+6qT2E/lngPEVt3tKS3j1hiVmJRbAKW9PymwWhedsH8Aq3AKN15dar+2SGH8YAaweqni1Jshp/JVkmmPaO9hHEDUdtXxBlciQQEI3FFUu/AY+qJNykwVDyOaM4paMsjpqA4PeDOQEuFTODcdkZEJawOvrgkDpE7Zkg1+odlnTRnE0Q==; 5:B+4zk/mdqDoLry94EmUyGTHzjfCzY7pTwAX7LQHLgq01pwfLNIePQ3GsTjLTXMhPg8zm7yNH8Id1IWwJwCOsgG0r0O/L2XFOqWaOmF7Z0k55sMub8LHHiMVbHyidncQ7IJFDX2KgDxgQLqFPjj7IglZH3lmreJ+O7S7jwmA2Z+w=; 7:kpHWC19DNAjdiq+ylQarqrhM5VCzenxQoxHx/orUYo4QtwPJibt8y3nVIMQ2vYxSduU+KBlZu4KQEhBi6yYMLeGuy7jfclEV01s7Mnr3n0W1m/o2y+5umLFOEOEMu1CWOS6RrMcTCLfJuxsrdNDrtIVNh2YaR0Ytn3RX5KprW5palaQncP7GjKrrbj9gtKnRB+isVgsSAa8DTAbqkJ5A88066+2a3evOzr4Bq+mrhqoHutROVSVQsBh5pBke1qrg x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 679f2c27-dac8-4399-68e6-08d6069f457c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM4PR05MB1683; x-ms-traffictypediagnostic: AM4PR05MB1683: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(823301075)(93006095)(93001095)(3231311)(944501410)(52105095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699016); SRVR:AM4PR05MB1683; BCL:0; PCL:0; RULEID:; SRVR:AM4PR05MB1683; x-forefront-prvs: 0770F75EA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(376002)(136003)(396003)(346002)(189003)(199004)(13464003)(6116002)(3846002)(33656002)(14444005)(5024004)(6436002)(7736002)(305945005)(76176011)(7696005)(9686003)(81156014)(53936002)(8676002)(81166006)(55016002)(8936002)(105586002)(5250100002)(229853002)(256004)(74316002)(106356001)(86362001)(68736007)(2906002)(2501003)(186003)(11346002)(14454004)(2900100001)(5660300001)(476003)(486006)(26005)(6506007)(102836004)(53546011)(446003)(25786009)(66066001)(99286004)(478600001)(6246003)(97736004)(54906003)(316002)(107886003)(110136005)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR05MB1683; H:AM4PR05MB3265.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: XwX2MtBbbBKKcrbTabnaKGBBkUZloFnE+Xc1oSzWAQ4gmAGIz0lRoDm0Wvd6redrjCcUnH7kadW0mp2FrPzzgx/Vz1ncM6quAU3PmSTcjl8vDtae7jOtVWZBe6HqkjF0hD0tUUvnJJLxA3Kxph8S59mVonNBmNMGgwVbb93H+V9P9SMezt/FpSgQwuSSGF7Qz7cMUfomGOzhyvy47a+Nw1xQ/NE9vjiI8H0ysuzao4verVKzLn6xQxBK3dOL4QZgsoXCASv/SB58EhDtR5RKARPwadDpB5YIxgvZREK1HTERO7pIRJ63+ahVbxieGyyprgumCsg2mC7sYP5b8noiX+bdROnG2Qh9Vdd6u1mN5ms= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 679f2c27-dac8-4399-68e6-08d6069f457c X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2018 13:17:25.3210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR05MB1683 Subject: Re: [dpdk-dev] [RFC] ethdev: flow counters batch query 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, 20 Aug 2018 13:17:28 -0000 Adding relevant maintainers. > -----Original Message----- > From: Slava Ovsiienko > Sent: Monday, August 20, 2018 14:39 > To: dev@dpdk.org > Cc: Shahaf Shuler ; Slava Ovsiienko > > Subject: [RFC] ethdev: flow counters batch query >=20 > There is a demand to perform query operations on the set of counters > generally belonging to the different RTE flows. The counter queries is th= e > very effective way for application to know in detail what is going on int= o the > network and to take some actions basing on this knowledge. As example, th= e > modern vSwitch implementation supporting full hardware offload may need > a huge number of counters and query these ones periodically for > configuration aging check purposes. >=20 > For some devices the counter query can be very expensive operation and > can take a significant amount of time - often it involves the calls of ke= rnel > mode components and performing requests to hardware. > If application wants to query multiple counters, belonging to the differe= nt > RTE flows, it has to execute queries in one-by-one fashion due to the cur= rent > RTE API implementation that allows to query counters belonging to the sam= e > flow only. The proposed RTE API extension introduces the compatible and > more performance way to allow applications to query the counter values as= a > batch. >=20 > At the creation the counter can be optionally assigned with the new > introduced 'group_id' identifier (batch identifier). All counters with th= e same > group_id form the new introduced entity > - 'counter batch'. The group_id specifies the unique batch within device = with > given port_id. The same group_id may specify the different batches on > different devices. >=20 > The new method 'rte_flow_query_update()' is proposed to perform the > counter batch query from the device as a single call, this eliminates a m= uch of > overhead involved with multiple quieries for the counters belonging to th= e > different flows. The rte_flow_query_update() fetches the actual counter > values from the device using underlying software and/or hardware and > stores obtained data into the counter objects within PMD. >=20 > The application can get the stored data by invoking the existing > rte_flow_query() method with specifying the new introduced flag > 'read_cached'. Such approach is compatible with the current > implementation, improves the performance and requires the minor changes > from applications. >=20 > Let's assume we have an array of flows and attached counters. > If application wants to read them it does something like that: >=20 > foreach(flow) { // compatible mode > rte_flow_query(flow, flow_counters[]); // no read_cached set > } // doing as previously >=20 > With counter batch query implemented application can do the following: >=20 > // new query mode > rte_flow_query_update(group_id of interest); // actual query here > foreach(flow) { // as single call > rte_flow_query(flow, flow_counters[]); // read_cached flag set > } // read stored data > // no underlying calls >=20 > For some devices implementation of rte_flow_query_update() may require > a lot of preparations before performing the actual query. If batch is > permanent and assumed not to be changed frequently the preparations can > be cached internally by implementation. By setting the > RTE_FLOW_QUERY_FLAG_PERMANENT flag application gives the hint to > PMD that batch is assumed to be long-term and allows to optimize the > succesive calls of rte_flow_query_update() for the same group_id on given > device. >=20 > If permanent batch is subject to change (occurs an adding or removing the > counter with specified batch id) the PMD should free all resources, inter= nally > allocated for batch query optimization. >=20 > If RTE_FLOW_QUERY_FLAG_PERMANENT is not set, > rte_flow_query_update() should free the resources allocated (including > ones done in previous calls, if any) for batch query optimization with gi= ven > group_id. >=20 > Signed-off-by: Viacheslav Ovsiienko > --- > doc/guides/prog_guide/rte_flow.rst | 76 > ++++++++++++++++++++++++++++---------- > lib/librte_ethdev/rte_flow.h | 59 ++++++++++++++++++++++++++++- > 2 files changed, 113 insertions(+), 22 deletions(-) >=20 > diff --git a/doc/guides/prog_guide/rte_flow.rst > b/doc/guides/prog_guide/rte_flow.rst > index b305a72..84b3b67 100644 > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -1500,6 +1500,10 @@ action must specify a unique id. > Counters can be retrieved and reset through ``rte_flow_query()``, see > ``struct rte_flow_query_count``. >=20 > +Counters can be assigned with group_id, all counters with matched > +group_id on the same port are grouped into batch and can be queried > +from device using the single call of rte_flow_query_update() > + > The shared flag indicates whether the counter is unique to the flow rule= the > action is specified with, or whether it is a shared counter. >=20 > @@ -1515,13 +1519,15 @@ to all ports within that switch domain. >=20 > .. table:: COUNT >=20 > - +------------+---------------------+ > - | Field | Value | > - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > - | ``shared`` | shared counter flag | > - +------------+---------------------+ > - | ``id`` | counter id | > - +------------+---------------------+ > + +--------------+----------------------+ > + | Field | Value | > + +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > + | ``shared`` | shared counter flag | > + +--------------+----------------------+ > + | ``id`` | counter id | > + +--------------+----------------------+ > + | ``group_id`` | batch id | > + +--------------+----------------------+ >=20 > Query structure to retrieve and reset flow rule counters: >=20 > @@ -1529,19 +1535,21 @@ Query structure to retrieve and reset flow rule > counters: >=20 > .. table:: COUNT query >=20 > - +---------------+-----+-----------------------------------+ > - | Field | I/O | Value | > - > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > + > - | ``reset`` | in | reset counter after query | > - +---------------+-----+-----------------------------------+ > - | ``hits_set`` | out | ``hits`` field is set | > - +---------------+-----+-----------------------------------+ > - | ``bytes_set`` | out | ``bytes`` field is set | > - +---------------+-----+-----------------------------------+ > - | ``hits`` | out | number of hits for this rule | > - +---------------+-----+-----------------------------------+ > - | ``bytes`` | out | number of bytes through this rule | > - +---------------+-----+-----------------------------------+ > + +-----------------+-----+-------------------------------------+ > + | Field | I/O | Value | > + > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D+=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D+ > + | ``reset`` | in | reset counter after query | > + +-----------------+-----+-------------------------------------+ > + | ``hits_set`` | out | ``hits`` field is set | > + +-----------------+-----+-------------------------------------+ > + | ``bytes_set`` | out | ``bytes`` field is set | > + +-----------------+-----+-------------------------------------+ > + | ``read_cached`` | in | read cached data instead of device | > + +-----------------+-----+-------------------------------------+ > + | ``hits`` | out | number of hits for this rule | > + +-----------------+-----+-------------------------------------+ > + | ``bytes`` | out | number of bytes through this rule | > + +-----------------+-----+-------------------------------------+ >=20 > Action: ``RSS`` > ^^^^^^^^^^^^^^^ > @@ -2288,6 +2296,34 @@ Return values: >=20 > - 0 on success, a negative errno value otherwise and ``rte_errno`` is se= t. >=20 > +Batch Query > +~~~~~~~~~~~ > + > +Query a batch of existing flow rules. > + > +This function allows retrieving flow-specific data such as counters > +belonging to the different flows on the given port in single batch > +query call. > + > +.. code-block:: c > + > + int > + rte_flow_query_update(uint16_t port_id, > + uint32_t group_id, > + uint32_t flags); > + > +Arguments: > + > +- ``port_id``: port identifier of Ethernet device. > +- ``group_id``: batch to query, specifies the group of actions. > +- ``flags``: can be combination of ``RTE_FLOW_QUERY_FLAG_RESET`` > + and ``RTE_FLOW_QUERY_FLAG_PERMANENT`` values > + > +Return values: > + > +- 0 on success, a negative errno value otherwise and ``rte_errno`` is se= t. > + > + > Isolated mode > ------------- >=20 > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h = index > f8ba71c..0cbc8fa 100644 > --- a/lib/librte_ethdev/rte_flow.h > +++ b/lib/librte_ethdev/rte_flow.h > @@ -1561,10 +1561,14 @@ struct rte_flow_action_queue { > * Counters can be retrieved and reset through ``rte_flow_query()``, see > * ``struct rte_flow_query_count``. > * > + * Counters can be assigned with group_id, all counters with matched > + group_id > + * on the same port are grouped into batch and can be queried from > + device > + * using the single call of rte_flow_query_update() > + * > * The shared flag indicates whether the counter is unique to the flow r= ule > the > * action is specified with, or whether it is a shared counter. > * > - * For a count action with the shared flag set, then then a global devic= e > + * For a count action with the shared flag set, then a global device > * namespace is assumed for the counter id, so that any matched flow rul= es > using > * a count action with the same counter id on the same port will contrib= ute > to > * that counter. > @@ -1576,6 +1580,7 @@ struct rte_flow_action_count { > uint32_t shared:1; /**< Share counter ID with other flow rules. */ > uint32_t reserved:31; /**< Reserved, must be zero. */ > uint32_t id; /**< Counter ID. */ > + uint32_t group_id; /**< ID of batch that counter belongs to */ > }; >=20 > /** > @@ -1587,7 +1592,8 @@ struct rte_flow_query_count { > uint32_t reset:1; /**< Reset counters after query [in]. */ > uint32_t hits_set:1; /**< hits field is set [out]. */ > uint32_t bytes_set:1; /**< bytes field is set [out]. */ > - uint32_t reserved:29; /**< Reserved, must be zero [in, out]. */ > + uint32_t read_cached:1; /**< read stored data instead of device [in]. > */ > + uint32_t reserved:28; /**< Reserved, must be zero [in, out]. */ > uint64_t hits; /**< Number of hits for this rule [out]. */ > uint64_t bytes; /**< Number of bytes through this rule [out]. */ }; > @@ -2094,6 +2100,55 @@ struct rte_flow * > struct rte_flow_error *error); >=20 > /** > + * Query a batch of existing flow rules. > + * > + * This function allows retrieving flow-specific data such as counters > + * belonging to the different flows on the given port in single batch > + * query call. > + * > + * \see RTE_FLOW_ACTION_TYPE_COUNT > + * > + * @param port_id > + * Port identifier of Ethernet device. > + * @param group_id > + * Batch identifier, specifies the group of actions to be queried. > + * @param flags > + * RTE_FLOW_QUERY_FLAG_RESET > + * RTE_FLOW_QUERY_FLAG_PERMANENT > + * > + * @return > + * 0 on success, a negative errno value otherwise and rte_errno is set= . > + */ > +int > +rte_flow_query_update(uint16_t port_id, > + uint32_t group_id, > + uint32_t flags); > + > +#define RTE_FLOW_QUERY_FLAG_RESET (1 << 0) /**< Reset counters after > +query */ > +/** > + * For some devices implementation of rte_flow_query_update() may > +require > + * a lot of preparations before performing the actual query. If batch > +is > + * permanent and assumed not to be changed frequently the preparations > + * can be cached internally by implementation. By setting the > + * RTE_FLOW_QUERY_FLAG_PERMANENT flag application gives the hint to > PMD > + * that batch is assumed to be long-term and allows to optimize the > + * succesive calls of rte_flow_query_update() for the same group_id > + * on given device. > + * > + * If permanent batch is subject to change (occurs an adding or > + * removing the action with specified batch id) the PMD should free all > + * resources, internally allocated for batch query optimization > + * > + * If RTE_FLOW_QUERY_FLAG_PERMANENT is not set, > rte_flow_query_update() > + * should free the resources (if any) early allocated for batch query > + * optimization with given group_id. > + * > + */ > +#define RTE_FLOW_QUERY_FLAG_PERMANENT (1 << 1) /**< Assume > batch > +permanent */ > + > +/** > * Restrict ingress traffic to the defined flow rules. > * > * Isolated mode guarantees that all ingress traffic comes from defined = flow > -- > 1.8.3.1