Message ID | 20220522105102.1692526-1-akozyrev@nvidia.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9B775A00C2; Sun, 22 May 2022 12:51:24 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 47BBF40156; Sun, 22 May 2022 12:51:24 +0200 (CEST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2050.outbound.protection.outlook.com [40.107.223.50]) by mails.dpdk.org (Postfix) with ESMTP id BC91C40040 for <dev@dpdk.org>; Sun, 22 May 2022 12:51:22 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SB8v6F3k9eYUld/aGNt7BlZcXarUab5JnhCAKWgSFi5Yj47ZP3wOy9TC3nt3UAAy0DxtLHwKfScyCh3Jr58flAcCLnIvy97BvY0aa40FIdxSia0wMfid72FRymGjw7M5dcrLSY8SHHWxJmqx8t4G9fWQVqqwP0X44nBzqq6nnlnikKos61tKDd7mbAiBRWNT2zMbRxzZBxf0mtkfJJG2nKhHIIaiWSVMdDGEMelAdqwPDxc6n1I2Z2XRIVZuzmQrmf3DaejvJTP+a9iG5K5zC90tpXPFRpHTVnFcp8k7noqqYxdn0YGsJL0bDnpgmDUZ6P66UO0wh9scTqVXD9udyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sgqtLZy0ZlJ/A2l2Sth2yK+wVq3lOCZRJHDrplVn/+8=; b=hYkZ7E/jEWtk2bVB1ZNpRwn4doOINH7YOL3dL7VT/mU9ieLY2VmQRZsArfF4tsUwb1WGVnFJY/fdzwSNdbqMxSCCxiqR9Vc6m/9ci7C9kSdMdRCt/26HSno8LiaixIW/4rmrcRXCK7YXE1aJ/uF5dqfau88wT6yq7zZvx4u0bAQnfOGM+mmKdSx6zQvQYxHGoRTYdAgqxV8GKHgSBCN55SqBTaaPE97CxwfceIylqB2mp9OnQpB1B8YYcabXmgDs83Zj3WJLrGTcwe+KjwALKOn4iepVLBwdWUVGFtkwpiiPxg/RZ3hnK8+dSIldD6P3rGkuLxtOfJgjOqnNGqF5fw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 12.22.5.234) smtp.rcpttodomain=intel.com smtp.mailfrom=nvidia.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=nvidia.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sgqtLZy0ZlJ/A2l2Sth2yK+wVq3lOCZRJHDrplVn/+8=; b=bf9n5kV7+MJX3Ju9McYcNkjaTsi+4JxtzManBs+jKvonte1Bp6vdA1ZTEVmvNtgJkAyRWVCGE1JqxKhhh/g/pyPeeBKZA7iTyW+dZY2YPUMq0/VBBs3Fxpv2iyCDgXcxWZcZDV0e56YDaSUWDe9/jq3OYZbq4eRJoOqXxbzjFAFYFL6JrnQWTF/u8aNvYYC3F2diWMl3l/Bqvetm+aV3iJBEnHpDzs36GzbFqT35++Z1uhrGj210IhwgS/KoFh2ifXgTmmxuA+7nTNrJBNwpA9g3lrGu89m2ZqEjtNcqfQQW3KXdpv51lg2KhK/W3/EjXpHGKhG4sWYewflT4zOdCQ== Received: from BN9PR03CA0245.namprd03.prod.outlook.com (2603:10b6:408:ff::10) by DM6PR12MB4123.namprd12.prod.outlook.com (2603:10b6:5:21f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5273.15; Sun, 22 May 2022 10:51:21 +0000 Received: from BN8NAM11FT032.eop-nam11.prod.protection.outlook.com (2603:10b6:408:ff:cafe::78) by BN9PR03CA0245.outlook.office365.com (2603:10b6:408:ff::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5273.14 via Frontend Transport; Sun, 22 May 2022 10:51:21 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 12.22.5.234) smtp.mailfrom=nvidia.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 12.22.5.234 as permitted sender) receiver=protection.outlook.com; client-ip=12.22.5.234; helo=mail.nvidia.com; pr=C Received: from mail.nvidia.com (12.22.5.234) by BN8NAM11FT032.mail.protection.outlook.com (10.13.177.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.5273.14 via Frontend Transport; Sun, 22 May 2022 10:51:20 +0000 Received: from rnnvmail201.nvidia.com (10.129.68.8) by DRHQMAIL101.nvidia.com (10.27.9.10) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Sun, 22 May 2022 10:51:19 +0000 Received: from pegasus01.mtr.labs.mlnx (10.126.230.35) by rnnvmail201.nvidia.com (10.129.68.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Sun, 22 May 2022 03:51:16 -0700 From: Alexander Kozyrev <akozyrev@nvidia.com> To: <dev@dpdk.org> CC: <orika@nvidia.com>, <thomas@monjalon.net>, <ivan.malov@oktetlabs.ru>, <andrew.rybchenko@oktetlabs.ru>, <ferruh.yigit@intel.com>, <mohammad.abdul.awal@intel.com>, <qi.z.zhang@intel.com>, <jerinj@marvell.com>, <ajit.khaparde@broadcom.com>, <bruce.richardson@intel.com> Subject: [PATCH v2 0/4] ethdev: separate metering and marking from policing Date: Sun, 22 May 2022 13:50:58 +0300 Message-ID: <20220522105102.1692526-1-akozyrev@nvidia.com> X-Mailer: git-send-email 2.18.2 In-Reply-To: <20220518043459.1281590-1-akozyrev@nvidia.com> References: <20220518043459.1281590-1-akozyrev@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.126.230.35] X-ClientProxiedBy: rnnvmail202.nvidia.com (10.129.68.7) To rnnvmail201.nvidia.com (10.129.68.8) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2d319aff-9e8b-4612-8f9f-08da3be1019d X-MS-TrafficTypeDiagnostic: DM6PR12MB4123:EE_ X-LD-Processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr X-Microsoft-Antispam-PRVS: <DM6PR12MB4123F755494C6CB5962FF89DAFD59@DM6PR12MB4123.namprd12.prod.outlook.com> X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dUTfJRHr0MbUSiKzU0SwphV6RudHeufskU2pHg5NvHUVQXAzsbTYo+4WWnkSPJMJ/MS3kB/SymZ7y0zIeA6pvZrr96PjU9PSAghaQ0m9fYIEuj4tWzQqJM1sFz8et7pQ1qFAYAUE0mqef9v6wx15dIFaTlpTKikePQWX+uWgxvPSJASX1RaUxEtoW5Mv/xUw9QpkWqYTnBNeQGv56qxPjviiLa/PG6owwAQdbivFzwWJT5ZgvXseXbsavCxSsv4V6SkSzo6mkd1ekmmV3fIAhwUBFmQDDLrF/bJKev+LTZMHfmflUsQ2Hn+7rqUOQXK/26/l5M9/Magn5hm5g79drIFWv7BuhT/pfUcwdCmEldwryLBN1WJEnEaXgzxFaUL4aykupalrjDLaRrD9+uPjgtijGYkJ1DznKNwD7Gdvtk0TTsMmy7C9dBGbpR3H43KfwAMb42tr5ITAO6RXG0tJtGn3QZlKx1pBFTvPHln9mqui3Mgwb/oJ2tBrIO5q2OdUSprAuDSaZrV4Eczc27x/lc973tcQv4wfsQyHb6kgt66J1u91aKcZOKeU0nARDWSt38tc9Ee/YB70B2xKiUWy1SHq8+jK7z4RwS60RLUztVandxBatzMJZZJ4ePa+/7rnqGywEbm6gXhV8pkAwuzPhFoQzail/eQhZOWhn1XV2xZka7MhmpdRQDPZaAqp7w2GLPqJ5rZKeZDav7L0nDXRFGuqtWrruGSXttWmx61i9gFNrFnHK6wWjOkvdbV+5sWwLFhPMdvGjvpWXakDsMxdQfCemVa+Zfq1EU0mAEVqMS4= X-Forefront-Antispam-Report: CIP:12.22.5.234; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:mail.nvidia.com; PTR:InfoNoRecords; CAT:NONE; SFS:(13230001)(4636009)(36840700001)(46966006)(40470700004)(36860700001)(86362001)(336012)(426003)(36756003)(40460700003)(47076005)(356005)(508600001)(316002)(26005)(81166007)(16526019)(8936002)(70586007)(70206006)(4326008)(186003)(966005)(82310400005)(83380400001)(1076003)(8676002)(7416002)(5660300002)(2906002)(54906003)(2616005)(6666004)(6916009)(36900700001); DIR:OUT; SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2022 10:51:20.5411 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2d319aff-9e8b-4612-8f9f-08da3be1019d X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a; Ip=[12.22.5.234]; Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-AuthSource: BN8NAM11FT032.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4123 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org |
Series |
ethdev: separate metering and marking from policing
|
|
Message
Alexander Kozyrev
May 22, 2022, 10:50 a.m. UTC
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 meter profile configuration cannot be updated dynamically
with the current set of patches, but can be supported later on.
Now you have to destroy flows and profiles and recreate them.
But rte_mtr_meter_profile_update()/rte_mtr_meter_policy_update()
can have the corresponding siblings without mtr_id parameters.
In this case, we can update the config and all the flows using them.
The meter sharing is done via the indirect action Flow API:
profile_id = rte_mtr_meter_profile_add(RFC_params);
*profile_obj_ptr = rte_mtr_meter_prof8ile_get(profile_id);
handle = rte_flow_action_handle_create(action=METER(profile_obj_ptr, NULL));
flow1 = rte_flow_create(pattern=5-tuple-1, actions=INDIRECT(handle));
flow2 = rte_flow_create(pattern=5-tuple-2, actions=INDIRECT(handle));
Once we are done with the flow rules we can free everything.
rte_flow_destroy(flow1);
rte_flow_destroy(flow2);
rte_flow_action_handle_destroy(handle);
rte_mtr_meter_profile_delete(profile_id);
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Alexander Kozyrev (4):
ethdev: add meter color flow matching item
ethdev: allow meter color marker modification
ethdev: get meter profile/policy objects
ethdev: add meter color mark flow action
doc/guides/prog_guide/rte_flow.rst | 32 ++++++++++
.../traffic_metering_and_policing.rst | 7 +++
doc/guides/rel_notes/release_22_07.rst | 7 +++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 60 +++++++++++++++++++
lib/ethdev/rte_mtr.c | 41 +++++++++++++
lib/ethdev/rte_mtr.h | 40 +++++++++++++
lib/ethdev/rte_mtr_driver.h | 19 ++++++
lib/ethdev/version.map | 2 +
9 files changed, 209 insertions(+)
Comments
Please add testpmd implenetation for this patch set. It can be part of each patch or just one patch. Best, Ori
On Sun, May 22, 2022 at 4:21 PM Alexander Kozyrev <akozyrev@nvidia.com> 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.
On Thu, May 26, 2022 at 6:51 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > On Sun, May 22, 2022 at 4:21 PM Alexander Kozyrev <akozyrev@nvidia.com> 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.
> On Thursday, May 26, 2022 9:23 Jerin Jacob <jerinjacobk@gmail.com> wrote: > > The overall approach looks good to me. > > > > Could you update > > doc/guides/prog_guide/traffic_metering_and_policing.rst for the new > > scheme. There is a documentation update in patch #3. > > 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. I believe that returning NULL pointer gives a hint that new approach is not supported. > 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. PMD patches will be sent to the mailing list shortly.