From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58FEBC433EF for ; Wed, 18 May 2022 16:51:29 +0000 (UTC) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 396D840156; Wed, 18 May 2022 18:51:28 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 36209400D6 for ; Wed, 18 May 2022 18:51:27 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 885DA8A; Wed, 18 May 2022 19:51:26 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 885DA8A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1652892686; bh=C5Ikowb4BjiMPrMhxlddDEYvLKrt8VQPXmr92fXU59E=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=NWRLjBII+vaO6N2kCS3KHjumLpyKs2StWgguwiMIEYF9XxMaWJVUcx9Uano2ruApV M+a4wwlxPdCXWc06A3r/OhCmdLsCCKk6WoF+W9V/XD6FR283uptx0IPcnGc8kklvOG zB6nMF7uQsz7lO64tH0DL3HXnMDnRT2QzDqnCr/U= Message-ID: Date: Wed, 18 May 2022 19:51:26 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [RFC] ethdev: datapath-focused meter actions, continue Content-Language: en-US To: Alexander Kozyrev , Ori Kam , Jerin Jacob , Cristian Dumitrescu , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , "Vipin.Varghese@amd.com" , Ajit Khaparde , Ferruh Yigit Cc: Ray Kinsella , Sunil Kumar Kori , Ivan Malov , "Awal, Mohammad Abdul" , "Zhang, Qi Z" , "Richardson, Bruce" , Konstantin Ananyev , "Singh, Jasvinder" , "dev@dpdk.org" References: From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 all, I'm sorry, I'm not sure that I can take part in tomorrow meeting, so, I'd like to drop my thoughts on the topic via E-mail. Existing "meter" object which pulls profile and policy together allows do apply metering in one flow-based lookup for different flows. I.e. we can route absolutely different flows to one meter object to share metering counters. When we know meter ID for a flow, everything becomes simple - just get corresponding metering counters, apply it and do actions based on color. Yes, it is not flexible, but very simple. As I understand the configuration model enforces to define actions for all colors. A new model, if I'm not mistaken, will require three flow-based lookups:  1. To assign a TAG based on flow fields (to handle different flows in one meter)  2. To do metering for packets with a TAG  3. To find actions based on color Of course, (2) and (3) are done in existing model with meter ID, but here it is a generic flow-based lookups with extra matching criteria. Yes, it is true that it gives extra flexibility, but everything has its price. Theoretically old model could be expressed using new one (and, therefore, supported on old HW), but it is a bit tricky and raises many questions on how to handle it correctly in all cases. E.g. if a TAG is the only pattern in non-zero table and used for meter+jump actions only, it could be associated with meter ID. Above jump table specified after meter action could be associated with a policy ID. If action for a color is not specified in a table, it should be drop by default. Indirect actions or action templates could help to do meter profile job - define profile in single place. To sum up, since some HW could support the flexibility provided by suggested flow API items/actions. I see no reason to block it. Solution looks good from flow API design point of view. May be I'm missing something since I'm not expert in QoS and have no hands-on experience with meters in DPDK. Andrew.