[dpdk-dev,1/3] ethdev: add new eth_dev_ops function for mtr ops get

  Following similar approach to rte_flow and rte_tm for modularity reasons.

Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
---
Changes in v1 (from RFC [1]):
- Removed ethdev API function to get the MTR ops, as it is not needed
  (input from Thomas)

[1] RFC: http://www.dpdk.org/ml/archives/dev/2017-May/066888.html

 lib/librte_ether/rte_ethdev.h | 6 ++++++
 1 file changed, 6 insertions(+)
  

-----Original Message-----
> Date: Sat, 26 Aug 2017 01:06:11 +0100
> From: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> To: dev@dpdk.org
> CC: thomas@monjalon.net, adrien.mazarguil@6wind.com,
>  jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com
> Subject: [PATCH 1/3] ethdev: add new eth_dev_ops function for mtr ops get
> X-Mailer: git-send-email 2.7.4
> 
> Following similar approach to rte_flow and rte_tm for modularity reasons.
> 
> Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> ---
> Changes in v1 (from RFC [1]):
> - Removed ethdev API function to get the MTR ops, as it is not needed
>   (input from Thomas)
> 
> [1] RFC: http://www.dpdk.org/ml/archives/dev/2017-May/066888.html
> 
>  lib/librte_ether/rte_ethdev.h | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index 0adf327..361c9bd 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -1421,6 +1421,9 @@ typedef int (*eth_filter_ctrl_t)(struct rte_eth_dev *dev,
>  typedef int (*eth_tm_ops_get_t)(struct rte_eth_dev *dev, void *ops);
>  /**< @internal Get Traffic Management (TM) operations on an Ethernet device */
>  
> +typedef int (*eth_mtr_ops_get_t)(struct rte_eth_dev *dev, void *ops);
> +/**< @internal Get Trafffic Metering and Policing (MTR) operations */
> +
>  typedef int (*eth_get_dcb_info)(struct rte_eth_dev *dev,
>  				 struct rte_eth_dcb_info *dcb_info);
>  /**< @internal Get dcb information on an Ethernet device */
> @@ -1544,6 +1547,9 @@ struct eth_dev_ops {
>  
>  	eth_tm_ops_get_t tm_ops_get;
>  	/**< Get Traffic Management (TM) operations. */
> +
> +	eth_mtr_ops_get_t mtr_ops_get;
> +	/**< Get Traffic Metering and Policing (MTR) operations. */

It will useful to have capability info here. In Cavium hardwares,
all input pkts are considered as green when they enqueue to ethdev tx
queue.

On the congestion control on Rx side, We support tail drop and RED per
mempool(not per RX queue)
  

Thanks for your input, Jerin!

<snip>...

> 
> It will useful to have capability info here. In Cavium hardwares,
> all input pkts are considered as green when they enqueue to ethdev tx
> queue.
> 

OK, will add capability API in V2.

> On the congestion control on Rx side, We support tail drop and RED per
> mempool(not per RX queue)

Regards,
Cristian
  

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                 |   24 +
 .../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, 2446 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