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 2D621A0558; Thu, 26 May 2022 15:23:07 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1B6D340151; Thu, 26 May 2022 15:23:07 +0200 (CEST) Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) by mails.dpdk.org (Postfix) with ESMTP id B0C3940150 for ; Thu, 26 May 2022 15:23:06 +0200 (CEST) Received: by mail-qv1-f45.google.com with SMTP id j3so1669894qvn.0 for ; Thu, 26 May 2022 06:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RKJZFs5sz1FPKp6vCP07zg9CWiSnxhYdNh8sJvx77Y4=; b=cT2XrfKqmu+U0Px5GnA9r7i/KGVhALf5bujPV+lwcWxXYx822s9NkFOYmNa5Qe+Gfv mO6nwN7u34qb3y2f2D3xdr259Lay3cbvN0K3S0BA5b26RhlQv85a09YezrKGlZiKCILK iaLZhjxr7/XnRl/DDyMBxfJ/DSVfiLn3KL1PGzCVLkohsM9PIDWxpXU3lIJ/L0fLEQw9 rD7y591mEpELZ23O3kfyesXtUnv8RuSiB2/kLDX3aEZuPlhwsGSRM3mLKJzhNPio48Km gddaGGS2KOBo22S98D+Udvg0jn3muMu2+kPiVm/Tvvn2mG8sKCuz5SSwG+pikrkuC8L6 PeFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RKJZFs5sz1FPKp6vCP07zg9CWiSnxhYdNh8sJvx77Y4=; b=iInqoz6fSHGMTZVxNQ1liswU+AA86wPmDFVlBuph7nqdM+VrTrQIfS6eEL8WO8hwHJ 5kk0Km3YC35qqATFNKZn+hVXpQEtCcp+d+lVutueR3WvR3Hnk+axrtGrNOA94extL2EM dx2qmqE2Cx7nLCyc7b1NlRxDtoetW0zt3oUBp7BZb/hOPNNB8faKtItZswo4B18IGPGD dyCeIOmjNUgMpQDTkmz5w0N7nJYO6MC5zdsHYc6mUUTPBZBf5fleMTKmbpJxWOUugtGa chNRlYYV+zi4NOl6tfT28iQk6KBlFq5GpoSMShIH6yIA1Gq+3LZyPV6Gt4j4xIpKPQ5e 2qkQ== X-Gm-Message-State: AOAM533p47jNgBUnyilRyGZzRlI1JVQ7R4Aosz4u6YYNeDc4hx7cqH/P 1QEB+vD4YrJ8yJF9H4AzReBXhNolP9/fsa4b/Z4= X-Google-Smtp-Source: ABdhPJw9OK5gx/nIlgxbcQE0uUQeFp74bw6e7ZNLua3Z+FzBZ2RnPEtlk8Xh7VTEqZYRW7/ffLkY5DyeDTs9YyLMumY= X-Received: by 2002:a05:6214:1cc4:b0:435:35c3:f0f1 with SMTP id g4-20020a0562141cc400b0043535c3f0f1mr30344022qvd.0.1653571386054; Thu, 26 May 2022 06:23:06 -0700 (PDT) MIME-Version: 1.0 References: <20220518043459.1281590-1-akozyrev@nvidia.com> <20220522105102.1692526-1-akozyrev@nvidia.com> In-Reply-To: From: Jerin Jacob Date: Thu, 26 May 2022 18:52:40 +0530 Message-ID: Subject: Re: [PATCH v2 0/4] ethdev: separate metering and marking from policing To: Alexander Kozyrev Cc: dpdk-dev , Ori Kam , Thomas Monjalon , Ivan Malov , Andrew Rybchenko , Ferruh Yigit , "Awal, Mohammad Abdul" , Qi Zhang , Jerin Jacob , Ajit Khaparde , "Richardson, Bruce" Content-Type: text/plain; charset="UTF-8" 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 On Thu, May 26, 2022 at 6:51 PM Jerin Jacob wrote: > > On Sun, May 22, 2022 at 4:21 PM Alexander Kozyrev wrote: > > > > Extend Metering and Marking support in the Flow API: > > 1. Add METER_COLOR item to match Color Marker set by a Meter. > > 2. Add the ability to set Color Marker via modify_field Flow API. > > 3. Add Meter API to get profile/policy objects. > > 4. Add METER_MARK action to perform Meter color metering and marking. > > Provide greater flexibility in how Metering can be used. > > > > RFC: https://patchwork.dpdk.org/project/dpdk/cover/20220502200439.4100965-1-akozyrev@nvidia.com/ > > > > Traditional Meter Usage: > > > > profile_id = rte_mtr_meter_profile_add(RFC_params); > > policy_id = rte_mtr_meter_policy_add(actions[RED/YELLOW/GREEN]); > > meter_id = rte_mtr_create(profile_id, policy_id); > > rte_flow_create(pattern=5-tuple,actions=METER(meter_id)); > > > > The METER action effectively translates to the following: > > 1. Metering a packet stream. > > 2. Marking packets with an appropriate color. > > 3. Jump to a policy group. > > 4. Match on a color. > > 5. Execute assigned policy actions for the color. > > > > New Meter Usage Model: > > profile_id = rte_mtr_meter_profile_add(RFC_params); > > *profile_obj_ptr = rte_mtr_meter_profile_get(profile_id); > > rte_flow_create(pattern=5-tuple, > > actions=METER(profile_obj_ptr),JUMP); > > rte_flow_create(pattern=COLOR, actions=...); > > > > The METER_MARK action effectively translates to the following: > > 1. Metering a packet stream. > > 2. Marking packets with an appropriate color. > > > > A user is able to match the color later with the COLOR item. > > In order to do this we add the JUMP action after the METER action. > > > > 3. Jump to a policy group. > > 4. Match on a color. > > 5. Execute actions for the color. > > > > Here we decoupled the meter profile usage from the meter policy usage > > for greater flexibility and got rid of any locks related to meter_id lookup. > > > > Another example of the meter creation to mimic the old model entirely: > > profile_id = rte_mtr_meter_profile_add(RFC_params); > > *profile_obj_ptr = rte_mtr_meter_profile_get(profile_id); > > policy_id = rte_mtr_meter_policy_add(actions[RED/YELLOW/GREEN]); > > *policy_obj_ptr = rte_mtr_meter_policy_get(policy_id); > > rte_flow_create(pattern=5-tuple, > > actions=METER(profile_obj_ptr, policy_obj_ptr)); > > > > In this case, we define the policy actions right away. > > The main advantage is not having to lookup for profile_id/policy_id. > > > > To free the meter obects we need to do the following: > > rte_flow_destroy(flow_handle); > > rte_mtr_meter_policy_delete(policy_id); > > rte_mtr_meter_profile_delete(profile_id);. > > profile_obj_ptr and policy_obj_ptr are no longer valid after that. > > The overall approach looks good to me. > > Could you update > doc/guides/prog_guide/traffic_metering_and_policing.rst for the new > scheme. > I think, we need to add "struct rte_mtr_capabilities" one more filed > for the capability for the application to > query to pick one way or another or both. Also, I think, the driver patches need to submit and merge before rc2 to avoid the case where there is no single implementation for API.