[dpdk-dev,V2,1/5] ethdev: add new flow action for metering and policing
Checks
Commit Message
Metering and policing action typically sits on top of flow classification,
which is why MTR objects are enabled through a newly introduced flow
action.
The configuration of MTR objects is done in their own namespace (rte_mtr)
within the librte_ether library. The MTR object is hooked into ethdev RX
processing path using the "meter" flow action.
Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
---
doc/guides/prog_guide/rte_flow.rst | 24 ++++++++++++++++++++++++
lib/librte_ether/rte_flow.h | 22 ++++++++++++++++++++++
2 files changed, 46 insertions(+)
Comments
On Thu, Oct 05, 2017 at 02:09:30PM +0100, Cristian Dumitrescu wrote:
> Metering and policing action typically sits on top of flow classification,
> which is why MTR objects are enabled through a newly introduced flow
> action.
>
> The configuration of MTR objects is done in their own namespace (rte_mtr)
> within the librte_ether library. The MTR object is hooked into ethdev RX
> processing path using the "meter" flow action.
>
> Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Looks good, one minor comment about the METER action semantics before acking
this patch, see below.
> ---
> doc/guides/prog_guide/rte_flow.rst | 24 ++++++++++++++++++++++++
> lib/librte_ether/rte_flow.h | 22 ++++++++++++++++++++++
> 2 files changed, 46 insertions(+)
>
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 662a912..6b9cdc2 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1354,6 +1354,30 @@ rule or if packets are not addressed to a VF in the first place.
> | ``vf`` | VF ID to redirect packets to |
> +--------------+--------------------------------+
>
> +Action: ``METER``
> +^^^^^^^^^^^^^^^^^
> +
> +Applies a stage of metering and policing.
> +
> +The metering and policing (MTR) object has to be first created using the
> +rte_mtr_create() API function. The ID of the MTR object is specified as
> +action parameter. One or several meter actions can be added to the same
> +flow. More than one flow can use the same MTR object through the meter
> +action. The MTR object can be further updated or queried using the
> +rte_mtr* API.
rte_flow is currently documented [1] as ignoring several actions of the same
kind in a given rule, in which case only the last one is taken into
account. It's a deliberate design choice to simplify implementation, which
I now think wasn't such a good idea after all.
I'm therefore not opposed to remove this restriction globally, however in
that case rte_flow documentation must be modified and PMDs reworked to
implement the new behavior (failing by default when encountering multiple
actions of the same time instead of ignoring them). It's probably a little
late to do this now though.
So my suggestion for the time being is to not describe what happens when
several MTR actions are provided. We'll keep this for the next overhaul of
rte_flow (some other changes are already planned).
[1] http://dpdk.org/doc/guides/prog_guide/rte_flow.html#actions
This patch set introduces an ethdev-based generic API for Traffic
Metering and Policing (MTR), which is yet another standard RX offload for
Ethernet devices.
Similar to rte_flow and rte_tm APIs, the configuration of MTR objects is
done in their own namespace (rte_mtr) within the librte_ether library.
Metering and policing action typically sits on top of flow classification,
which is why MTR objects are enabled through a newly introduced flow
action, which is the only impact to flow API.
Q1: Why introduce ethdev-based traffic metering ad policing API?
A1: Traffic metering and policing is a standard RX offload for Ethernet
devices present in NICs, SoCs and NPUs across the industry.
Q2: What's the connection between the new rte_mtr API and the existing
librte_meter library?
A2: The existing librte_meter library provides a SW implementation for a
subset of the features exposed by this API. The rte_mtr API is agnostic to
whether the implementation is HW, SW or mixed HW-SW.
Q3: What's the connection between the new rte_mtr API and the existing
flow API?
A3: The MTR object is hooked into ethdev RX processing path using a newly
introduced flow action, which is the only impact to the flow API.
The configuration of MTR objects is done in separate namespace (rte_mtr)
outside of flow API.
Q4: Can the new flow API meter action drop packets? Is this a terminating
action or not?
A4: Although packets can be dropped by the newly introduced flow API meter
action, this action is non-terminating, i.e. the action list typically
contains at least one more action, which is a terminating action.
Depending on the policer actions configured for the MTR object, some
packets might be dropped while some packets passed to the next flow action
with their color set in the packet mbuf. For example, a typical policer
configuration is to drop the red packets while passing the green packets,
therefore a subsequent flow action needs to be configured to determine the
final destination of green packets.
Q5: Which are the main operations exposed for the MTR object?
A5: Traffic metering, policing and statistics update. 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, recolor or drop the packet. Stats are
maintained for MTR object, as configured.
Q6: Where is the output color stored for the current packet.
A6: struct rte_mbuf::sched::color.
Q7: Which are the supported metering algorithms?
A7: srTCM (RFC 2697), trTCM (RFC 2698 and RFC 4115).
Q8: Which are the supported policer actions?
A8: Recolor the packet (keep or change the color determined by metering)
or drop the packet.
Cristian Dumitrescu (5):
ethdev: add new flow action for metering and policing
ethdev: add new eth_dev_ops function for mtr ops get
ethdev: add new api for traffic metering and policing
doc: ethdev traffic metering and policing api
app/testpmd: cli for traffic metering and policing
MAINTAINERS | 4 +
app/test-pmd/Makefile | 1 +
app/test-pmd/cmdline.c | 10 +
app/test-pmd/cmdline_flow.c | 24 +
app/test-pmd/cmdline_mtr.c | 1013 ++++++++++++++++++++
app/test-pmd/cmdline_mtr.h | 49 +
doc/api/doxy-api-index.md | 1 +
doc/guides/prog_guide/index.rst | 1 +
doc/guides/prog_guide/rte_flow.rst | 23 +
.../prog_guide/traffic_metering_and_policing.rst | 97 ++
lib/librte_ether/Makefile | 3 +
lib/librte_ether/rte_ethdev.h | 6 +
lib/librte_ether/rte_ethdev_version.map | 18 +
lib/librte_ether/rte_flow.h | 22 +
lib/librte_ether/rte_mtr.c | 229 +++++
lib/librte_ether/rte_mtr.h | 723 ++++++++++++++
lib/librte_ether/rte_mtr_driver.h | 221 +++++
17 files changed, 2445 insertions(+)
create mode 100644 app/test-pmd/cmdline_mtr.c
create mode 100644 app/test-pmd/cmdline_mtr.h
create mode 100644 doc/guides/prog_guide/traffic_metering_and_policing.rst
create mode 100644 lib/librte_ether/rte_mtr.c
create mode 100644 lib/librte_ether/rte_mtr.h
create mode 100644 lib/librte_ether/rte_mtr_driver.h
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Friday, October 6, 2017 2:58 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: dev@dpdk.org; thomas@monjalon.net; Wu, Jingjing
> <jingjing.wu@intel.com>; hemant.agrawal@nxp.com;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>
> Subject: Re: [PATCH V2 1/5] ethdev: add new flow action for metering and
> policing
>
> On Thu, Oct 05, 2017 at 02:09:30PM +0100, Cristian Dumitrescu wrote:
> > Metering and policing action typically sits on top of flow classification,
> > which is why MTR objects are enabled through a newly introduced flow
> > action.
> >
> > The configuration of MTR objects is done in their own namespace (rte_mtr)
> > within the librte_ether library. The MTR object is hooked into ethdev RX
> > processing path using the "meter" flow action.
> >
> > Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
>
> Looks good, one minor comment about the METER action semantics before
> acking
> this patch, see below.
>
> > ---
> > doc/guides/prog_guide/rte_flow.rst | 24 ++++++++++++++++++++++++
> > lib/librte_ether/rte_flow.h | 22 ++++++++++++++++++++++
> > 2 files changed, 46 insertions(+)
> >
> > diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> > index 662a912..6b9cdc2 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -1354,6 +1354,30 @@ rule or if packets are not addressed to a VF in
> the first place.
> > | ``vf`` | VF ID to redirect packets to |
> > +--------------+--------------------------------+
> >
> > +Action: ``METER``
> > +^^^^^^^^^^^^^^^^^
> > +
> > +Applies a stage of metering and policing.
> > +
> > +The metering and policing (MTR) object has to be first created using the
> > +rte_mtr_create() API function. The ID of the MTR object is specified as
> > +action parameter. One or several meter actions can be added to the same
> > +flow. More than one flow can use the same MTR object through the
> meter
> > +action. The MTR object can be further updated or queried using the
> > +rte_mtr* API.
>
> rte_flow is currently documented [1] as ignoring several actions of the same
> kind in a given rule, in which case only the last one is taken into
> account. It's a deliberate design choice to simplify implementation, which
> I now think wasn't such a good idea after all.
>
> I'm therefore not opposed to remove this restriction globally, however in
> that case rte_flow documentation must be modified and PMDs reworked to
> implement the new behavior (failing by default when encountering multiple
> actions of the same time instead of ignoring them). It's probably a little
> late to do this now though.
>
> So my suggestion for the time being is to not describe what happens when
> several MTR actions are provided. We'll keep this for the next overhaul of
> rte_flow (some other changes are already planned).
Hi Adrian,
Done in V3 just sent.
Thanks,
Cristian
>
> [1] http://dpdk.org/doc/guides/prog_guide/rte_flow.html#actions
>
> --
> Adrien Mazarguil
> 6WIND
@@ -1354,6 +1354,30 @@ rule or if packets are not addressed to a VF in the first place.
| ``vf`` | VF ID to redirect packets to |
+--------------+--------------------------------+
+Action: ``METER``
+^^^^^^^^^^^^^^^^^
+
+Applies a stage of metering and policing.
+
+The metering and policing (MTR) object has to be first created using the
+rte_mtr_create() API function. The ID of the MTR object is specified as
+action parameter. One or several meter actions can be added to the same
+flow. More than one flow can use the same MTR object through the meter
+action. The MTR object can be further updated or queried using the
+rte_mtr* API.
+
+- Non-terminating by default.
+
+.. _table_rte_flow_action_meter:
+
+.. table:: METER
+
+ +--------------+---------------+
+ | Field | Value |
+ +==============+===============+
+ | ``mtr_id`` | MTR object ID |
+ +--------------+---------------+
+
Negative types
~~~~~~~~~~~~~~
@@ -915,6 +915,14 @@ enum rte_flow_action_type {
* See struct rte_flow_action_vf.
*/
RTE_FLOW_ACTION_TYPE_VF,
+
+ /**
+ * Traffic metering and policing (MTR).
+ *
+ * See struct rte_flow_action_meter.
+ * See file rte_mtr.h for MTR object configuration.
+ */
+ RTE_FLOW_ACTION_TYPE_METER,
};
/**
@@ -1008,6 +1016,20 @@ struct rte_flow_action_vf {
};
/**
+ * RTE_FLOW_ACTION_TYPE_METER
+ *
+ * Traffic metering and policing (MTR).
+ *
+ * Packets matched by items of this type can be either dropped or passed to the
+ * next item with their color set by the MTR object.
+ *
+ * Non-terminating by default.
+ */
+struct rte_flow_action_meter {
+ uint32_t mtr_id; /**< MTR object ID created with rte_mtr_create(). */
+};
+
+/**
* Definition of a single action.
*
* A list of actions is terminated by a END action.