5f0d54f372
Currently, the flow meter policy does not support multiple actions per color; also the allowed action types per color are very limited. In addition, the policy cannot be pre-defined. Due to the growing in flow actions offload abilities there is a potential for the user to use variety of actions per color differently. This new meter policy API comes to allow this potential in the most ethdev common way using rte_flow action definition. A list of rte_flow actions will be provided by the user per color in order to create a meter policy. In addition, the API forces to pre-define the policy before the meters creation in order to allow sharing of single policy with multiple meters efficiently. meter_policy_id is added into struct rte_mtr_params. So that it can get the policy during the meters creation. Allow coloring the packet using a new rte_flow_action_color as could be done by the old policy API. Add two common policy template as macros in the head file. The next API function were added: - rte_mtr_meter_policy_add - rte_mtr_meter_policy_delete - rte_mtr_meter_policy_update - rte_mtr_meter_policy_validate The next struct was changed: - rte_mtr_params - rte_mtr_capabilities The next API was deleted: - rte_mtr_policer_actions_update To support this API the following app were changed: app/test-flow-perf: clean meter policer app/testpmd: clean meter policer To support this API the following drivers were changed: net/softnic: support meter policy API 1. Cleans meter rte_mtr_policer_action. 2. Supports policy API to get color action as policer action did. The color action will be mapped into rte_table_action_policer. net/mlx5: clean meter creation management Cleans and breaks part of the current meter management in order to allow better design with policy API. Signed-off-by: Li Zhang <lizh@nvidia.com> Signed-off-by: Haifei Luo <haifeil@nvidia.com> Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com> Acked-by: Matan Azrad <matan@nvidia.com> Acked-by: Ray Kinsella <mdr@ashroe.eu> Acked-by: Ori Kam <orika@nvidia.com> Acked-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
67 lines
2.7 KiB
ReStructuredText
67 lines
2.7 KiB
ReStructuredText
.. SPDX-License-Identifier: BSD-3-Clause
|
|
Copyright(c) 2017 Intel Corporation.
|
|
|
|
Traffic Metering and Policing API
|
|
=================================
|
|
|
|
|
|
Overview
|
|
--------
|
|
|
|
This is the generic API for the Quality of Service (QoS) Traffic Metering and
|
|
Policing (MTR) of Ethernet devices. This API is agnostic of the underlying HW,
|
|
SW or mixed HW-SW implementation.
|
|
|
|
The main features are:
|
|
|
|
* Part of DPDK rte_ethdev API
|
|
* Capability query API
|
|
* Metering algorithms: RFC 2697 Single Rate Three Color Marker (srTCM), RFC 2698
|
|
and RFC 4115 Two Rate Three Color Marker (trTCM)
|
|
* Policer actions (per meter output color): recolor, drop
|
|
* Statistics (per policer output color)
|
|
|
|
Configuration steps
|
|
-------------------
|
|
|
|
The metering and policing stage typically sits on top of flow classification,
|
|
which is why the MTR objects are enabled through a special "meter" action.
|
|
|
|
The MTR objects are created and updated in their own name space (``rte_mtr``)
|
|
within the ``librte_ethdev`` library. Whether an MTR object is private to a
|
|
flow or potentially shared by several flows has to be specified at its
|
|
creation time.
|
|
|
|
Once successfully created, an MTR object is hooked into the RX processing path
|
|
of the Ethernet device by linking it to one or several flows through the
|
|
dedicated "meter" flow action. One or several "meter" actions can be registered
|
|
for the same flow. An MTR object can only be destroyed if there are no flows
|
|
using it.
|
|
|
|
Run-time processing
|
|
-------------------
|
|
|
|
Traffic metering determines the color for the current packet (green, yellow,
|
|
red) based on the previous history for this flow as maintained by the MTR
|
|
object. The policer can do nothing, override the color the packet or drop the
|
|
packet. Statistics counters are maintained for MTR object, as configured.
|
|
|
|
The processing done for each input packet hitting an MTR object is:
|
|
|
|
* Traffic metering: The packet is assigned a color (the meter output color)
|
|
based on the previous traffic history reflected in the current state of the
|
|
MTR object, according to the specific traffic metering algorithm. The
|
|
traffic metering algorithm can typically work in color aware mode, in which
|
|
case the input packet already has an initial color (the input color), or in
|
|
color blind mode, which is equivalent to considering all input packets
|
|
initially colored as green.
|
|
|
|
* There is a meter policy API to manage pre-defined policies for meter.
|
|
Any rte_flow action list can be configured per color for each policy.
|
|
A meter object configured with a policy executes the actions per packet
|
|
according to the packet color.
|
|
|
|
* Statistics: The set of counters maintained for each MTR object is
|
|
configurable and subject to the implementation support. This set includes
|
|
the number of packets and bytes dropped or passed for each output color.
|