Re: [dpdk-dev] [RFC] Support metering policy for yellow color in mlx5 PMD

["Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>]

Hi Bing,

I am not entirely sure what your question is; if your question is: can I use all the features of the API, then the answer is definitely YES :).

> -----Original Message-----
> From: Bing Zhao <bingz@nvidia.com>
> Sent: Wednesday, June 2, 2021 2:25 PM
> To: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; Li Zhang
> <lizh@nvidia.com>
> Cc: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; NBU-Contact-
> Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; andrew.rybchenko@oktetlabs.ru; dev@dpdk.org
> Subject: [RFC] Support metering policy for yellow color in mlx5 PMD
> 
> The current API of metering can support different policies for different
> colors, as described in the header file "rte_mtr.h".
> 
> /**
> * Meter policy
> */
> struct rte_mtr_meter_policy_params {
>                 /**
>                 * Policy action list per color.
>                 * actions[i] potentially represents a chain of rte_flow actions
>                 * terminated by the END action, exactly as specified by the rte_flow
>                 * API for the flow definition, and not just a single action.
>                 */
>                 const struct rte_flow_action *actions[RTE_COLORS];
> };
> 
> In the real-life, when doing QoS or traffic shaping with metering, there is no
> restriction of the packets handling for different colors. After the metering,
> the packet will be marked with different colors and it is the application's
> responsibility to decide the next step of handling packets with different
> colors. The policies of different colors can be either the same or different.
> 
> In the current implementation of mlx5 PMD, when adding a meter policy,
> only
> the actions list for GREEN was supported, like RSS, queue, mark, etc., but no
> support for YELLOW. The support of policy actions of YELLOW color is added
> to
> provide better flexibility.
> 
>   1. The actions to be supported are as same as those for GREEN, including
>      terminating and non-terminating actions.
>   2. The policies of GREEN and YELLOW colors are independent.
>   3. When RSS is used for both GREEN and YELLOW in one policy parameter,
>      except the queues list, all the other configurations of RSS should be
>      the same, like level, hash fields, and so on.
>   4. No change for the RED color is needed, and the default behavior should
>      still be the "drop".

If your HW supports it, why hardcode the RED action to drop and not allow people to set up any set of actions they want (as long as supported by the HW) for the RED packets?

Yes, drop might be a typical action that some users will set for the RED packets, but I don't see any reason to have this restricted by the driver (unless the drop action is the only action supported by the HW for the RED packets).

> 
> The testpmd command line example is like below:
> 
> add port meter profile srtcm_rfc2697 0 24 65536 1024 0 0
> add port meter policy 0 1 g_actions rss queues 0 end types udp end / end
> y_actions rss queues 1 end types udp end / end r_actions drop / end
> create port meter 0 1 24 1 yes 0xffff 1 0
> ...
> 
> The actions list configuration for different colors in testpmd CLI was
> already supported. There is no major change needed for the testpmd CLI.
> 
> Signed-off-by: Bing Zhao <bingz@nvidia.com>

Regards,
Cristian