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 E4010A0503; Thu, 19 May 2022 11:43:01 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8786C40156; Thu, 19 May 2022 11:43:01 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 18DF240150 for ; Thu, 19 May 2022 11:43:00 +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 55B178A; Thu, 19 May 2022 12:42:59 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 55B178A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1652953379; bh=YyEvkj1Vp8tweFmdy723byiIfyMijJKElz8LZ46j/lU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Cd1XNirKCcQ957YR7gmQkpEjzrgbOYmpiOZMPKeTA31zmwWr+uYm29+pcpnZIgwym 0t/5KggodDeEl3m9V9Qixyd7Tg7zoBW//goYcZDVQKF8kiFwe69pfCyxbJ7fmEAvMU Rn/mCv5X2naXwcL5NMmZeisiAMNxvBvlZ5uk/6cQ= Message-ID: <127733f3-2685-c91b-51b1-60acf4617899@oktetlabs.ru> Date: Thu, 19 May 2022 12:42:58 +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: Ori Kam , Alexander Kozyrev , 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 Ori, On 5/19/22 11:41, Ori Kam wrote: > Hi Andrew, > >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Thursday, May 19, 2022 9:45 AM >> Subject: Re: [RFC] ethdev: datapath-focused meter actions, continue >> >> On 5/19/22 05:17, Alexander Kozyrev wrote: >>> On Wed, May 18, 2022 12:51 Andrew Rybchenko : >>>> 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. >>> >>> Thank you for taking some time and reviewing this RFC. >>> >>>> 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. >>> >>> Yes, and what I propose is the flexible version of Meters where both >>> profiles and policies can be used separately. But flexibility comes with >>> a price of taking care of both of them separately as well, of course. >>> >>>> 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. >>> >>> We don't need to assign a TAG. I used the TAG as example on how we can >>> combine color matching with any other item matching. Model stays the same. >>> You still do color marking with a meter and find actions based on a color. >> >> I general yes, but I've tried to highlight the case when the >> same meter should be applied to different flows. If so, you >> need a way to combine. Old way allows to do it in a single step - just >> specify meter ID. New way needs extra rule, for example, >> using TAG or MARK. >> > If you want the same meter to be used by different rules, you can just > use the action handle (indirect action). Good point. I've missed such usage of an indirect action. > The tag is used in order to demux the rules after the color matching. > > Example for such use case: > You have a share meter for a user, The user has number of connections, > (Youtube, web, game) > So the first thing the application does it checks the user meter > Group 0: > Match (user youtube 5 tuple) actions shared_meter set_tag(youtube) jump to group 1 > Match (user web 5 tuple) actions shared_meter set_tag(web) jump to group 1 > Match (user game 5 tuple) actions shared_meter set_tag(game) jump to group 1 > > Group 1: (this is what we currently call profile,) > Match color == green jump group 2 > Match color == red drop > > Group 2: > Match tag == youtube actions youtube related actions > Match tag == web actions web related actions > Match tag == game actions game related actions > > Using the new API you can combine Group 1 and 2 (group 2 will no be needed anymore) > Group 1': > Match tag == youtube and color == green actions youtube related actions > Match tag == weband color == green actions web related actions > Match tag == game and color == green actions game related actions > Match color == red drop > > As you can see, to implement the logic in current API we must use 3 groups while, > using the suggested APi we can just use 2 groups. > > >>> >>>> 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. >>> >>> Yes, old model can be expressed via new API and new model can be >>> simulated with the old API. Efficiency and performance is the key. >>> >>>> Indirect actions or action templates could help to do meter profile job >>>> - define profile in single place. >>> >>> True, meter color marking may be used for meter sharing, for example. >>> >>>> 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. >>> >>> Thank you. >>> >>>> May be I'm missing something since I'm not expert in QoS and have no >>>> hands-on experience with meters in DPDK. >>>> >>>> Andrew. >>> >