* [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features
@ 2021-08-20 8:24 jerinj
2021-08-30 9:23 ` Jerin Jacob
` (2 more replies)
0 siblings, 3 replies; 30+ messages in thread
From: jerinj @ 2021-08-20 8:24 UTC (permalink / raw)
To: Cristian Dumitrescu, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko
Cc: dev, arybchenko, lizh, ajit.khaparde, jasvinder.singh, matan,
ndabilpuram, skori, rkudurumalla, Jerin Jacob
From: Jerin Jacob <jerinj@marvell.com>
Currently, meter object supports only DSCP based on input color table,
The patch enhance that to support VLAN based input color table,
color table based on inner field for the tunnel use case, and support
for fallback color per meter if packet based on a different field.
All of the above features are exposed through capability and added
additional capability to specify the implementation supports
more than one input color table per ethdev port.
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---
lib/ethdev/rte_mtr.h | 130 ++++++++++++++++++++++++++++++++++++++-----
1 file changed, 116 insertions(+), 14 deletions(-)
diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h
index dc246dd7af..311e8754de 100644
--- a/lib/ethdev/rte_mtr.h
+++ b/lib/ethdev/rte_mtr.h
@@ -213,6 +213,16 @@ struct rte_mtr_meter_policy_params {
const struct rte_flow_action *actions[RTE_COLORS];
};
+/**
+ * Input color table
+ */
+enum rte_mtr_input_color_tbl {
+ /** DSCP based input color table */
+ RTE_MTR_INPUT_COLOR_TBL_DSCP,
+ /** VLAN based input color table */
+ RTE_MTR_INPUT_COLOR_TBL_VLAN,
+};
+
/**
* Parameters for each traffic metering & policing object
*
@@ -233,20 +243,44 @@ struct rte_mtr_params {
*/
int use_prev_mtr_color;
- /** Meter input color. When non-NULL: it points to a pre-allocated and
- * pre-populated table with exactly 64 elements providing the input
- * color for each value of the IPv4/IPv6 Differentiated Services Code
- * Point (DSCP) input packet field. When NULL: it is equivalent to
- * setting this parameter to an all-green populated table (i.e. table
- * with all the 64 elements set to green color). The color blind mode
- * is configured by setting *use_prev_mtr_color* to 0 and *dscp_table*
- * to either NULL or to an all-green populated table. When
- * *use_prev_mtr_color* is non-zero value or when *dscp_table* contains
- * at least one yellow or red color element, then the color aware mode
- * is configured.
- */
- enum rte_color *dscp_table;
-
+ RTE_STD_C11
+ union {
+ /** Meter input color based on DSCP.
+ * Valid when rte_mtr_input_color_tbl::tbl_selector is
+ * set to RTE_MTR_INPUT_COLOR_TBL_DSCP.
+ * When non-NULL: it points to a pre-allocated and pre-populated
+ * table with exactly 64 elements providing the input color for
+ * each value of the IPv4/IPv6 Differentiated Services Code
+ * Point (DSCP) input packet field. When NULL:
+ * it is equivalent to setting this parameter to an all-green
+ * populated table (i.e. table with
+ * all the 64 elements set to green color). The color blind mode
+ * is configured by setting *use_prev_mtr_color* to 0 and
+ * *dscp_table* to either NULL or to an all-green
+ * populated table. When *use_prev_mtr_color* is non-zero value
+ * or when *dscp_table* contains at least one yellow or
+ * red color element, then the color aware mode is configured.
+ * @see struct rte_mtr_capabilities::input_color_dscp_supported
+ */
+ enum rte_color *dscp_table;
+ /** Meter input color based on VLAN.
+ * Valid when rte_mtr_input_color_tbl::tbl_selector is
+ * set to RTE_MTR_INPUT_COLOR_TBL_VLAN.
+ * When non-NULL: it points to a pre-allocated and pre-populated
+ * table with exactly 16 elements providing the input color for
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ * When NULL: it is equivalent to setting this parameter to an
+ * all-green populated table (i.e. table with
+ * all the 16 elements set to green color). The color blind mode
+ * is configured by setting *use_prev_mtr_color* to 0 and
+ * *vlan_table* to either NULL or to an all-green
+ * populated table. When *use_prev_mtr_color* is non-zero value
+ * or when *vlan_table* contains at least one yellow or
+ * red color element, then the color aware mode is configured.
+ * @see struct rte_mtr_capabilities::input_color_vlan_supported
+ */
+ enum rte_color *vlan_table;
+ };
/** Non-zero to enable the meter, zero to disable the meter at the time
* of MTR object creation. Ignored when the meter profile indicated by
* *meter_profile_id* is set to NONE.
@@ -261,6 +295,25 @@ struct rte_mtr_params {
/** Meter policy ID. */
uint32_t meter_policy_id;
+
+ /** Select the input color table
+ * @see struct rte_mtr_params::dscp_table
+ * @see struct rte_mtr_capabilities::input_color_dscp_supported
+ * @see struct rte_mtr_params::vlan_table
+ * @see struct rte_mtr_capabilities::input_color_vlan_supported
+ */
+ enum rte_mtr_input_color_tbl tbl_selector;
+ /** Fallback input color for the meter,
+ * when *use_prev_mtr_color* set to zero value and
+ * when packet is not based on selected *tbl_selector*.
+ * @see struct rte_mtr_capabilities::input_color_fallback_supported
+ */
+ enum rte_color fallback_input_color;
+ /** Input color table based on inner field of selected
+ * of *tbl_selector*.
+ * @see struct rte_mtr_capabilities::input_color_inner_supported
+ */
+ int input_color_inner_enable;
};
/**
@@ -417,6 +470,31 @@ struct rte_mtr_capabilities {
* @see enum rte_mtr_stats_type
*/
uint64_t stats_mask;
+
+ /** Input color based on DSCP.
+ * When non-zero, it indicates that driver supports input color table
+ * based on DSCP.
+ */
+ int input_color_dscp_supported;
+ /** Input color based on VLAN.
+ * When non-zero, it indicates that driver supports input color table
+ * based on VLAN.
+ */
+ int input_color_vlan_supported;
+ /** Input color fallback support.
+ * When non-zero, it indicates that driver supports input color
+ * fallback.
+ */
+ int input_color_fallback_supported;
+ /** Input color based on inner packet field.
+ * When non-zero, it indicates that driver supports input color
+ * based on inner field.
+ */
+ int input_color_inner_supported;
+ /** When non-zero, it indicates that driver supports separate
+ * input color table for given ethdev port.
+ */
+ int seperate_input_color_table_per_port;
};
/**
@@ -832,6 +910,30 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
enum rte_color *dscp_table,
struct rte_mtr_error *error);
+/**
+ * MTR object VLAN table update
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[in] vlan_table
+ * When non-NULL: it points to a pre-allocated and pre-populated table with
+ * exactly 16 elements providing the input color for each value of the
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ * When NULL: it is equivalent to setting this parameter to an "all-green"
+ * populated table (i.e. table with all the 16 elements set to green color).
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+__rte_experimental
+int
+rte_mtr_meter_vlan_table_update(uint16_t port_id,
+ uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error);
/**
* MTR object enabled statistics counters update
*
--
2.33.0
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features
2021-08-20 8:24 [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features jerinj
@ 2021-08-30 9:23 ` Jerin Jacob
2021-09-27 16:20 ` Ferruh Yigit
2021-10-11 15:14 ` Dumitrescu, Cristian
2022-02-14 11:56 ` [dpdk-dev] [v22.07] [PATCH] ethdev: mtr: support input color selection jerinj
2 siblings, 1 reply; 30+ messages in thread
From: Jerin Jacob @ 2021-08-30 9:23 UTC (permalink / raw)
To: Jerin Jacob
Cc: Cristian Dumitrescu, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko, dpdk-dev, Andrew Rybchenko, Li Zhang,
Ajit Khaparde, Jasvinder Singh, Matan Azrad, Nithin Dabilpuram,
Sunil Kumar Kori, rkudurumalla
Ping
On Fri, Aug 20, 2021 at 1:56 PM <jerinj@marvell.com> wrote:
>
> From: Jerin Jacob <jerinj@marvell.com>
>
> Currently, meter object supports only DSCP based on input color table,
> The patch enhance that to support VLAN based input color table,
> color table based on inner field for the tunnel use case, and support
> for fallback color per meter if packet based on a different field.
>
> All of the above features are exposed through capability and added
> additional capability to specify the implementation supports
> more than one input color table per ethdev port.
>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> ---
> lib/ethdev/rte_mtr.h | 130 ++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 116 insertions(+), 14 deletions(-)
>
> diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h
> index dc246dd7af..311e8754de 100644
> --- a/lib/ethdev/rte_mtr.h
> +++ b/lib/ethdev/rte_mtr.h
> @@ -213,6 +213,16 @@ struct rte_mtr_meter_policy_params {
> const struct rte_flow_action *actions[RTE_COLORS];
> };
>
> +/**
> + * Input color table
> + */
> +enum rte_mtr_input_color_tbl {
> + /** DSCP based input color table */
> + RTE_MTR_INPUT_COLOR_TBL_DSCP,
> + /** VLAN based input color table */
> + RTE_MTR_INPUT_COLOR_TBL_VLAN,
> +};
> +
> /**
> * Parameters for each traffic metering & policing object
> *
> @@ -233,20 +243,44 @@ struct rte_mtr_params {
> */
> int use_prev_mtr_color;
>
> - /** Meter input color. When non-NULL: it points to a pre-allocated and
> - * pre-populated table with exactly 64 elements providing the input
> - * color for each value of the IPv4/IPv6 Differentiated Services Code
> - * Point (DSCP) input packet field. When NULL: it is equivalent to
> - * setting this parameter to an all-green populated table (i.e. table
> - * with all the 64 elements set to green color). The color blind mode
> - * is configured by setting *use_prev_mtr_color* to 0 and *dscp_table*
> - * to either NULL or to an all-green populated table. When
> - * *use_prev_mtr_color* is non-zero value or when *dscp_table* contains
> - * at least one yellow or red color element, then the color aware mode
> - * is configured.
> - */
> - enum rte_color *dscp_table;
> -
> + RTE_STD_C11
> + union {
> + /** Meter input color based on DSCP.
> + * Valid when rte_mtr_input_color_tbl::tbl_selector is
> + * set to RTE_MTR_INPUT_COLOR_TBL_DSCP.
> + * When non-NULL: it points to a pre-allocated and pre-populated
> + * table with exactly 64 elements providing the input color for
> + * each value of the IPv4/IPv6 Differentiated Services Code
> + * Point (DSCP) input packet field. When NULL:
> + * it is equivalent to setting this parameter to an all-green
> + * populated table (i.e. table with
> + * all the 64 elements set to green color). The color blind mode
> + * is configured by setting *use_prev_mtr_color* to 0 and
> + * *dscp_table* to either NULL or to an all-green
> + * populated table. When *use_prev_mtr_color* is non-zero value
> + * or when *dscp_table* contains at least one yellow or
> + * red color element, then the color aware mode is configured.
> + * @see struct rte_mtr_capabilities::input_color_dscp_supported
> + */
> + enum rte_color *dscp_table;
> + /** Meter input color based on VLAN.
> + * Valid when rte_mtr_input_color_tbl::tbl_selector is
> + * set to RTE_MTR_INPUT_COLOR_TBL_VLAN.
> + * When non-NULL: it points to a pre-allocated and pre-populated
> + * table with exactly 16 elements providing the input color for
> + * each value of the DEI(1bit), PCP(3 bits) input packet field.
> + * When NULL: it is equivalent to setting this parameter to an
> + * all-green populated table (i.e. table with
> + * all the 16 elements set to green color). The color blind mode
> + * is configured by setting *use_prev_mtr_color* to 0 and
> + * *vlan_table* to either NULL or to an all-green
> + * populated table. When *use_prev_mtr_color* is non-zero value
> + * or when *vlan_table* contains at least one yellow or
> + * red color element, then the color aware mode is configured.
> + * @see struct rte_mtr_capabilities::input_color_vlan_supported
> + */
> + enum rte_color *vlan_table;
> + };
> /** Non-zero to enable the meter, zero to disable the meter at the time
> * of MTR object creation. Ignored when the meter profile indicated by
> * *meter_profile_id* is set to NONE.
> @@ -261,6 +295,25 @@ struct rte_mtr_params {
>
> /** Meter policy ID. */
> uint32_t meter_policy_id;
> +
> + /** Select the input color table
> + * @see struct rte_mtr_params::dscp_table
> + * @see struct rte_mtr_capabilities::input_color_dscp_supported
> + * @see struct rte_mtr_params::vlan_table
> + * @see struct rte_mtr_capabilities::input_color_vlan_supported
> + */
> + enum rte_mtr_input_color_tbl tbl_selector;
> + /** Fallback input color for the meter,
> + * when *use_prev_mtr_color* set to zero value and
> + * when packet is not based on selected *tbl_selector*.
> + * @see struct rte_mtr_capabilities::input_color_fallback_supported
> + */
> + enum rte_color fallback_input_color;
> + /** Input color table based on inner field of selected
> + * of *tbl_selector*.
> + * @see struct rte_mtr_capabilities::input_color_inner_supported
> + */
> + int input_color_inner_enable;
> };
>
> /**
> @@ -417,6 +470,31 @@ struct rte_mtr_capabilities {
> * @see enum rte_mtr_stats_type
> */
> uint64_t stats_mask;
> +
> + /** Input color based on DSCP.
> + * When non-zero, it indicates that driver supports input color table
> + * based on DSCP.
> + */
> + int input_color_dscp_supported;
> + /** Input color based on VLAN.
> + * When non-zero, it indicates that driver supports input color table
> + * based on VLAN.
> + */
> + int input_color_vlan_supported;
> + /** Input color fallback support.
> + * When non-zero, it indicates that driver supports input color
> + * fallback.
> + */
> + int input_color_fallback_supported;
> + /** Input color based on inner packet field.
> + * When non-zero, it indicates that driver supports input color
> + * based on inner field.
> + */
> + int input_color_inner_supported;
> + /** When non-zero, it indicates that driver supports separate
> + * input color table for given ethdev port.
> + */
> + int seperate_input_color_table_per_port;
> };
>
> /**
> @@ -832,6 +910,30 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
> enum rte_color *dscp_table,
> struct rte_mtr_error *error);
>
> +/**
> + * MTR object VLAN table update
> + *
> + * @param[in] port_id
> + * The port identifier of the Ethernet device.
> + * @param[in] mtr_id
> + * MTR object ID. Needs to be valid.
> + * @param[in] vlan_table
> + * When non-NULL: it points to a pre-allocated and pre-populated table with
> + * exactly 16 elements providing the input color for each value of the
> + * each value of the DEI(1bit), PCP(3 bits) input packet field.
> + * When NULL: it is equivalent to setting this parameter to an "all-green"
> + * populated table (i.e. table with all the 16 elements set to green color).
> + * @param[out] error
> + * Error details. Filled in only on error, when not NULL.
> + * @return
> + * 0 on success, non-zero error code otherwise.
> + */
> +__rte_experimental
> +int
> +rte_mtr_meter_vlan_table_update(uint16_t port_id,
> + uint32_t mtr_id,
> + enum rte_color *vlan_table,
> + struct rte_mtr_error *error);
> /**
> * MTR object enabled statistics counters update
> *
> --
> 2.33.0
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features
2021-08-30 9:23 ` Jerin Jacob
@ 2021-09-27 16:20 ` Ferruh Yigit
0 siblings, 0 replies; 30+ messages in thread
From: Ferruh Yigit @ 2021-09-27 16:20 UTC (permalink / raw)
To: Cristian Dumitrescu
Cc: Thomas Monjalon, Andrew Rybchenko, dpdk-dev, Andrew Rybchenko,
Li Zhang, Ajit Khaparde, Jasvinder Singh, Matan Azrad,
Nithin Dabilpuram, Sunil Kumar Kori, rkudurumalla, Jerin Jacob,
Jerin Jacob
On 8/30/2021 10:23 AM, Jerin Jacob wrote:
> Ping
>
>
> On Fri, Aug 20, 2021 at 1:56 PM <jerinj@marvell.com> wrote:
>>
>> From: Jerin Jacob <jerinj@marvell.com>
>>
>> Currently, meter object supports only DSCP based on input color table,
>> The patch enhance that to support VLAN based input color table,
>> color table based on inner field for the tunnel use case, and support
>> for fallback color per meter if packet based on a different field.
>>
>> All of the above features are exposed through capability and added
>> additional capability to specify the implementation supports
>> more than one input color table per ethdev port.
>>
>> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
Hi Cristian,
Reminder of this set, can you please review it?
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features
2021-08-20 8:24 [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features jerinj
2021-08-30 9:23 ` Jerin Jacob
@ 2021-10-11 15:14 ` Dumitrescu, Cristian
2021-11-17 12:00 ` Jerin Jacob
2022-02-14 11:56 ` [dpdk-dev] [v22.07] [PATCH] ethdev: mtr: support input color selection jerinj
2 siblings, 1 reply; 30+ messages in thread
From: Dumitrescu, Cristian @ 2021-10-11 15:14 UTC (permalink / raw)
To: jerinj, Thomas Monjalon, Yigit, Ferruh, Andrew Rybchenko
Cc: dev, arybchenko, lizh, ajit.khaparde, Singh, Jasvinder, matan,
ndabilpuram, skori, rkudurumalla
Hi Jerin,
> -----Original Message-----
> From: jerinj@marvell.com <jerinj@marvell.com>
> Sent: Friday, August 20, 2021 9:24 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; Andrew
> Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Cc: dev@dpdk.org; arybchenko@solarflare.com; lizh@nvidia.com;
> ajit.khaparde@broadcom.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>; matan@nvidia.com;
> ndabilpuram@marvell.com; skori@marvell.com; rkudurumalla@marvell.com;
> Jerin Jacob <jerinj@marvell.com>
> Subject: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table
> features
>
> From: Jerin Jacob <jerinj@marvell.com>
>
> Currently, meter object supports only DSCP based on input color table,
> The patch enhance that to support VLAN based input color table,
> color table based on inner field for the tunnel use case, and support
> for fallback color per meter if packet based on a different field.
>
> All of the above features are exposed through capability and added
> additional capability to specify the implementation supports
> more than one input color table per ethdev port.
>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> ---
> lib/ethdev/rte_mtr.h | 130
> ++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 116 insertions(+), 14 deletions(-)
>
> diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h
> index dc246dd7af..311e8754de 100644
> --- a/lib/ethdev/rte_mtr.h
> +++ b/lib/ethdev/rte_mtr.h
> @@ -213,6 +213,16 @@ struct rte_mtr_meter_policy_params {
> const struct rte_flow_action *actions[RTE_COLORS];
> };
>
> +/**
> + * Input color table
> + */
> +enum rte_mtr_input_color_tbl {
> + /** DSCP based input color table */
> + RTE_MTR_INPUT_COLOR_TBL_DSCP,
> + /** VLAN based input color table */
> + RTE_MTR_INPUT_COLOR_TBL_VLAN,
> +};
> +
> /**
> * Parameters for each traffic metering & policing object
> *
> @@ -233,20 +243,44 @@ struct rte_mtr_params {
> */
> int use_prev_mtr_color;
>
> - /** Meter input color. When non-NULL: it points to a pre-allocated
> and
> - * pre-populated table with exactly 64 elements providing the input
> - * color for each value of the IPv4/IPv6 Differentiated Services Code
> - * Point (DSCP) input packet field. When NULL: it is equivalent to
> - * setting this parameter to an all-green populated table (i.e. table
> - * with all the 64 elements set to green color). The color blind mode
> - * is configured by setting *use_prev_mtr_color* to 0 and
> *dscp_table*
> - * to either NULL or to an all-green populated table. When
> - * *use_prev_mtr_color* is non-zero value or when *dscp_table*
> contains
> - * at least one yellow or red color element, then the color aware
> mode
> - * is configured.
> - */
> - enum rte_color *dscp_table;
> -
> + RTE_STD_C11
> + union {
> + /** Meter input color based on DSCP.
> + * Valid when rte_mtr_input_color_tbl::tbl_selector is
> + * set to RTE_MTR_INPUT_COLOR_TBL_DSCP.
> + * When non-NULL: it points to a pre-allocated and pre-
> populated
> + * table with exactly 64 elements providing the input color for
> + * each value of the IPv4/IPv6 Differentiated Services Code
> + * Point (DSCP) input packet field. When NULL:
> + * it is equivalent to setting this parameter to an all-green
> + * populated table (i.e. table with
> + * all the 64 elements set to green color). The color blind
> mode
> + * is configured by setting *use_prev_mtr_color* to 0 and
> + * *dscp_table* to either NULL or to an all-green
> + * populated table. When *use_prev_mtr_color* is non-zero
> value
> + * or when *dscp_table* contains at least one yellow or
> + * red color element, then the color aware mode is
> configured.
> + * @see struct
> rte_mtr_capabilities::input_color_dscp_supported
> + */
> + enum rte_color *dscp_table;
> + /** Meter input color based on VLAN.
> + * Valid when rte_mtr_input_color_tbl::tbl_selector is
> + * set to RTE_MTR_INPUT_COLOR_TBL_VLAN.
> + * When non-NULL: it points to a pre-allocated and pre-
> populated
> + * table with exactly 16 elements providing the input color for
> + * each value of the DEI(1bit), PCP(3 bits) input packet field.
> + * When NULL: it is equivalent to setting this parameter to an
> + * all-green populated table (i.e. table with
> + * all the 16 elements set to green color). The color blind
> mode
> + * is configured by setting *use_prev_mtr_color* to 0 and
> + * *vlan_table* to either NULL or to an all-green
> + * populated table. When *use_prev_mtr_color* is non-zero
> value
> + * or when *vlan_table* contains at least one yellow or
> + * red color element, then the color aware mode is
> configured.
> + * @see struct
> rte_mtr_capabilities::input_color_vlan_supported
> + */
> + enum rte_color *vlan_table;
> + };
> /** Non-zero to enable the meter, zero to disable the meter at the
> time
> * of MTR object creation. Ignored when the meter profile indicated
> by
> * *meter_profile_id* is set to NONE.
> @@ -261,6 +295,25 @@ struct rte_mtr_params {
>
> /** Meter policy ID. */
> uint32_t meter_policy_id;
> +
> + /** Select the input color table
> + * @see struct rte_mtr_params::dscp_table
> + * @see struct rte_mtr_capabilities::input_color_dscp_supported
> + * @see struct rte_mtr_params::vlan_table
> + * @see struct rte_mtr_capabilities::input_color_vlan_supported
> + */
> + enum rte_mtr_input_color_tbl tbl_selector;
> + /** Fallback input color for the meter,
> + * when *use_prev_mtr_color* set to zero value and
> + * when packet is not based on selected *tbl_selector*.
> + * @see struct rte_mtr_capabilities::input_color_fallback_supported
> + */
> + enum rte_color fallback_input_color;
> + /** Input color table based on inner field of selected
> + * of *tbl_selector*.
> + * @see struct rte_mtr_capabilities::input_color_inner_supported
> + */
> + int input_color_inner_enable;
> };
>
> /**
> @@ -417,6 +470,31 @@ struct rte_mtr_capabilities {
> * @see enum rte_mtr_stats_type
> */
> uint64_t stats_mask;
> +
> + /** Input color based on DSCP.
> + * When non-zero, it indicates that driver supports input color table
> + * based on DSCP.
> + */
> + int input_color_dscp_supported;
> + /** Input color based on VLAN.
> + * When non-zero, it indicates that driver supports input color table
> + * based on VLAN.
> + */
> + int input_color_vlan_supported;
> + /** Input color fallback support.
> + * When non-zero, it indicates that driver supports input color
> + * fallback.
> + */
> + int input_color_fallback_supported;
> + /** Input color based on inner packet field.
> + * When non-zero, it indicates that driver supports input color
> + * based on inner field.
> + */
> + int input_color_inner_supported;
> + /** When non-zero, it indicates that driver supports separate
> + * input color table for given ethdev port.
> + */
> + int seperate_input_color_table_per_port;
> };
>
> /**
> @@ -832,6 +910,30 @@ rte_mtr_meter_dscp_table_update(uint16_t
> port_id,
> enum rte_color *dscp_table,
> struct rte_mtr_error *error);
>
> +/**
> + * MTR object VLAN table update
> + *
> + * @param[in] port_id
> + * The port identifier of the Ethernet device.
> + * @param[in] mtr_id
> + * MTR object ID. Needs to be valid.
> + * @param[in] vlan_table
> + * When non-NULL: it points to a pre-allocated and pre-populated table
> with
> + * exactly 16 elements providing the input color for each value of the
> + * each value of the DEI(1bit), PCP(3 bits) input packet field.
> + * When NULL: it is equivalent to setting this parameter to an "all-green"
> + * populated table (i.e. table with all the 16 elements set to green color).
> + * @param[out] error
> + * Error details. Filled in only on error, when not NULL.
> + * @return
> + * 0 on success, non-zero error code otherwise.
> + */
> +__rte_experimental
> +int
> +rte_mtr_meter_vlan_table_update(uint16_t port_id,
> + uint32_t mtr_id,
> + enum rte_color *vlan_table,
> + struct rte_mtr_error *error);
> /**
> * MTR object enabled statistics counters update
> *
> --
> 2.33.0
Allowing the configuration of the packet input color based on multiple protocols as opposed to just IP DSCP field makes sense to me.
A few questions/suggestions:
1. How do we decide which field/protocol takes precedence to define the packet input color? You are enabling 2 possible options so far, i.e. VLAN tag PCP field and IP DSCP field, which one is to be set for the current meter object? Using the capabilities to decide is confusing, as a specific meter object might be able to support multiple or even all the possible options (e.g. the meter object is fine with either IP DSCP or VLAN PCP). Therefore, we need a clear mechanism to unequivocally pick one; I think the user must explicitly define which input color methodology is to be used by explicitly setting a field (to be added) in the meter object parameter structure.
2. What if the defined input color methodology is not applicable to the current input packet? For example, the user selects VLAN PCP, but some or all of the input packets do not contain any VLAN labels?
3. How do we manage the many packet fields that could be used as the key for the input color: outer IP DSCP, inner IP DSCP, VLAN 1st label, VLAN 2nd label, MPLS QoS, etc?
- Approach A: Use an enumeration, like you propose, and we can add more in the future. Not ideal.
- Approach B: Point to a protocol-agnostic packet field by defining the offset and mask of a 64-bit field. Advantage: we don't need to change the API every time we add a new option.
4. I suggest we use a unified input color table as opposed to one per protocol, i.e. rename the struct rte_mtr_params::dscp_table to color_in_table. The size of this table could be implicitly defined by the packet field type (in case of enum) or the field mask (in case of protocol-agnostic field offset and mask), as described above.
Regards,
Cristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features
2021-10-11 15:14 ` Dumitrescu, Cristian
@ 2021-11-17 12:00 ` Jerin Jacob
2021-12-07 9:55 ` Jerin Jacob
0 siblings, 1 reply; 30+ messages in thread
From: Jerin Jacob @ 2021-11-17 12:00 UTC (permalink / raw)
To: Dumitrescu, Cristian
Cc: jerinj, Thomas Monjalon, Yigit, Ferruh, Andrew Rybchenko, dev,
arybchenko, lizh, ajit.khaparde, Singh, Jasvinder, matan,
ndabilpuram, skori, rkudurumalla
On Mon, Oct 11, 2021 at 8:53 PM Dumitrescu, Cristian
<cristian.dumitrescu@intel.com> wrote:
>
> Hi Jerin,
Hi Cristian,
>
> > -----Original Message-----
> > From: jerinj@marvell.com <jerinj@marvell.com>
> > Sent: Friday, August 20, 2021 9:24 AM
> > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Thomas Monjalon
> > <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; Andrew
> > Rybchenko <andrew.rybchenko@oktetlabs.ru>
> > Cc: dev@dpdk.org; arybchenko@solarflare.com; lizh@nvidia.com;
> > ajit.khaparde@broadcom.com; Singh, Jasvinder
> > <jasvinder.singh@intel.com>; matan@nvidia.com;
> > ndabilpuram@marvell.com; skori@marvell.com; rkudurumalla@marvell.com;
> > Jerin Jacob <jerinj@marvell.com>
> > Subject: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table
> > features
> >
> > From: Jerin Jacob <jerinj@marvell.com>
> >
> > Currently, meter object supports only DSCP based on input color table,
> > The patch enhance that to support VLAN based input color table,
> > color table based on inner field for the tunnel use case, and support
> > for fallback color per meter if packet based on a different field.
> >
> > All of the above features are exposed through capability and added
> > additional capability to specify the implementation supports
> > more than one input color table per ethdev port.
> >
> > Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> > 2.33.0
>
> Allowing the configuration of the packet input color based on multiple protocols as opposed to just IP DSCP field makes sense to me.
>
Apologies for the delay in response. This was missed the 21.11
timeframe so I don't bother replying. Reviving back.
> A few questions/suggestions:
>
> 1. How do we decide which field/protocol takes precedence to define the packet input color? You are enabling 2 possible options so far, i.e. VLAN tag PCP field and IP DSCP field, which one is to be set for the current meter object? Using the capabilities to decide is confusing, as a specific meter object might be able to support multiple or even all the possible options (e.g. the meter object is fine with either IP DSCP or VLAN PCP). Therefore, we need a clear mechanism to unequivocally pick one; I think the user must explicitly define which input color methodology is to be used by explicitly setting a field (to be added) in the meter object parameter structure.
Currently, in our HW, Each meter object needs to tell which pre-color
scheme it is going to use(IP DSCP or VLAN PCP). This is OK in the
overall scheme of things as the meter object is connected to rte_flow.
So,
rte_flow pattern can decide the steering to meter. Having said that,
it is possible to have array for input color as you suggested. If
choose that, path, We need to add capability tell implementation
supports only one input color per meter object. Let me know if this is
OK.
>
> 2. What if the defined input color methodology is not applicable to the current input packet? For example, the user selects VLAN PCP, but some or all of the input packets do not contain any VLAN labels?
it picks the rte_mtr_params::fallback_input_color
>
> 3. How do we manage the many packet fields that could be used as the key for the input color: outer IP DSCP, inner IP DSCP, VLAN 1st label, VLAN 2nd label, MPLS QoS, etc?
> - Approach A: Use an enumeration, like you propose, and we can add more in the future. Not ideal.
> - Approach B: Point to a protocol-agnostic packet field by defining the offset and mask of a 64-bit field. Advantage: we don't need to change the API every time we add a new option.
No strong opinion on doing Approach B. I think, it may be overkill for
application and implementation to express. No strong opinion, If you
have a strong opinion on that, I will change that to v1. Let me know.
>
> 4. I suggest we use a unified input color table as opposed to one per protocol, i.e. rename the struct rte_mtr_params::dscp_table to color_in_table. The size of this table could be implicitly defined by the packet field type (in case of enum) or the field mask (in case of protocol-agnostic field offset and mask), as described above.
Will do that. I thought not to do that just because, I don't want to
remove the existing dscp_table symbol.
Make sense to enable your suggestion.
Let me know your views on Questions 1 and 3. I will send the next
version based on that.
>
> Regards,
> Cristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features
2021-11-17 12:00 ` Jerin Jacob
@ 2021-12-07 9:55 ` Jerin Jacob
2021-12-07 18:00 ` Dumitrescu, Cristian
0 siblings, 1 reply; 30+ messages in thread
From: Jerin Jacob @ 2021-12-07 9:55 UTC (permalink / raw)
To: Dumitrescu, Cristian
Cc: jerinj, Thomas Monjalon, Yigit, Ferruh, Andrew Rybchenko, dev,
arybchenko, lizh, ajit.khaparde, Singh, Jasvinder, matan,
ndabilpuram, skori, rkudurumalla
On Wed, Nov 17, 2021 at 5:30 PM Jerin Jacob <jerinjacobk@gmail.com> wrote:
>
> On Mon, Oct 11, 2021 at 8:53 PM Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com> wrote:
> >
> > Hi Jerin,
>
Hi Cristian,
Could you share your feedback so that I can send the v1?
>
>
> >
> > > -----Original Message-----
> > > From: jerinj@marvell.com <jerinj@marvell.com>
> > > Sent: Friday, August 20, 2021 9:24 AM
> > > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Thomas Monjalon
> > > <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; Andrew
> > > Rybchenko <andrew.rybchenko@oktetlabs.ru>
> > > Cc: dev@dpdk.org; arybchenko@solarflare.com; lizh@nvidia.com;
> > > ajit.khaparde@broadcom.com; Singh, Jasvinder
> > > <jasvinder.singh@intel.com>; matan@nvidia.com;
> > > ndabilpuram@marvell.com; skori@marvell.com; rkudurumalla@marvell.com;
> > > Jerin Jacob <jerinj@marvell.com>
> > > Subject: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table
> > > features
> > >
> > > From: Jerin Jacob <jerinj@marvell.com>
> > >
> > > Currently, meter object supports only DSCP based on input color table,
> > > The patch enhance that to support VLAN based input color table,
> > > color table based on inner field for the tunnel use case, and support
> > > for fallback color per meter if packet based on a different field.
> > >
> > > All of the above features are exposed through capability and added
> > > additional capability to specify the implementation supports
> > > more than one input color table per ethdev port.
> > >
> > > Signed-off-by: Jerin Jacob <jerinj@marvell.com>
>
> > > 2.33.0
> >
> > Allowing the configuration of the packet input color based on multiple protocols as opposed to just IP DSCP field makes sense to me.
> >
>
> Apologies for the delay in response. This was missed the 21.11
> timeframe so I don't bother replying. Reviving back.
>
> > A few questions/suggestions:
> >
> > 1. How do we decide which field/protocol takes precedence to define the packet input color? You are enabling 2 possible options so far, i.e. VLAN tag PCP field and IP DSCP field, which one is to be set for the current meter object? Using the capabilities to decide is confusing, as a specific meter object might be able to support multiple or even all the possible options (e.g. the meter object is fine with either IP DSCP or VLAN PCP). Therefore, we need a clear mechanism to unequivocally pick one; I think the user must explicitly define which input color methodology is to be used by explicitly setting a field (to be added) in the meter object parameter structure.
>
> Currently, in our HW, Each meter object needs to tell which pre-color
> scheme it is going to use(IP DSCP or VLAN PCP). This is OK in the
> overall scheme of things as the meter object is connected to rte_flow.
> So,
> rte_flow pattern can decide the steering to meter. Having said that,
> it is possible to have array for input color as you suggested. If
> choose that, path, We need to add capability tell implementation
> supports only one input color per meter object. Let me know if this is
> OK.
>
>
> >
> > 2. What if the defined input color methodology is not applicable to the current input packet? For example, the user selects VLAN PCP, but some or all of the input packets do not contain any VLAN labels?
>
> it picks the rte_mtr_params::fallback_input_color
>
> >
> > 3. How do we manage the many packet fields that could be used as the key for the input color: outer IP DSCP, inner IP DSCP, VLAN 1st label, VLAN 2nd label, MPLS QoS, etc?
> > - Approach A: Use an enumeration, like you propose, and we can add more in the future. Not ideal.
> > - Approach B: Point to a protocol-agnostic packet field by defining the offset and mask of a 64-bit field. Advantage: we don't need to change the API every time we add a new option.
>
> No strong opinion on doing Approach B. I think, it may be overkill for
> application and implementation to express. No strong opinion, If you
> have a strong opinion on that, I will change that to v1. Let me know.
>
>
> >
> > 4. I suggest we use a unified input color table as opposed to one per protocol, i.e. rename the struct rte_mtr_params::dscp_table to color_in_table. The size of this table could be implicitly defined by the packet field type (in case of enum) or the field mask (in case of protocol-agnostic field offset and mask), as described above.
>
> Will do that. I thought not to do that just because, I don't want to
> remove the existing dscp_table symbol.
> Make sense to enable your suggestion.
>
> Let me know your views on Questions 1 and 3. I will send the next
> version based on that.
>
>
>
> >
> > Regards,
> > Cristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features
2021-12-07 9:55 ` Jerin Jacob
@ 2021-12-07 18:00 ` Dumitrescu, Cristian
2022-01-10 9:35 ` Jerin Jacob
0 siblings, 1 reply; 30+ messages in thread
From: Dumitrescu, Cristian @ 2021-12-07 18:00 UTC (permalink / raw)
To: Jerin Jacob
Cc: jerinj, Thomas Monjalon, Yigit, Ferruh, Andrew Rybchenko, dev,
arybchenko, lizh, ajit.khaparde, Singh, Jasvinder, matan,
ndabilpuram, skori, rkudurumalla
HI Jerin,
Sorry for my delay. I am currently in vacation until the beginning on January 2022, so my response is slower than usual.
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Tuesday, December 7, 2021 9:55 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: jerinj@marvell.com; Thomas Monjalon <thomas@monjalon.net>; Yigit,
> Ferruh <ferruh.yigit@intel.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org;
> arybchenko@solarflare.com; lizh@nvidia.com;
> ajit.khaparde@broadcom.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>; matan@nvidia.com;
> ndabilpuram@marvell.com; skori@marvell.com; rkudurumalla@marvell.com
> Subject: Re: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table
> features
>
> On Wed, Nov 17, 2021 at 5:30 PM Jerin Jacob <jerinjacobk@gmail.com>
> wrote:
> >
> > On Mon, Oct 11, 2021 at 8:53 PM Dumitrescu, Cristian
> > <cristian.dumitrescu@intel.com> wrote:
> > >
> > > Hi Jerin,
> >
> Hi Cristian,
>
> Could you share your feedback so that I can send the v1?
>
>
> >
> >
> > >
> > > > -----Original Message-----
> > > > From: jerinj@marvell.com <jerinj@marvell.com>
> > > > Sent: Friday, August 20, 2021 9:24 AM
> > > > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Thomas
> Monjalon
> > > > <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>;
> Andrew
> > > > Rybchenko <andrew.rybchenko@oktetlabs.ru>
> > > > Cc: dev@dpdk.org; arybchenko@solarflare.com; lizh@nvidia.com;
> > > > ajit.khaparde@broadcom.com; Singh, Jasvinder
> > > > <jasvinder.singh@intel.com>; matan@nvidia.com;
> > > > ndabilpuram@marvell.com; skori@marvell.com;
> rkudurumalla@marvell.com;
> > > > Jerin Jacob <jerinj@marvell.com>
> > > > Subject: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color
> table
> > > > features
> > > >
> > > > From: Jerin Jacob <jerinj@marvell.com>
> > > >
> > > > Currently, meter object supports only DSCP based on input color table,
> > > > The patch enhance that to support VLAN based input color table,
> > > > color table based on inner field for the tunnel use case, and support
> > > > for fallback color per meter if packet based on a different field.
> > > >
> > > > All of the above features are exposed through capability and added
> > > > additional capability to specify the implementation supports
> > > > more than one input color table per ethdev port.
> > > >
> > > > Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> >
> > > > 2.33.0
> > >
> > > Allowing the configuration of the packet input color based on multiple
> protocols as opposed to just IP DSCP field makes sense to me.
> > >
> >
> > Apologies for the delay in response. This was missed the 21.11
> > timeframe so I don't bother replying. Reviving back.
> >
> > > A few questions/suggestions:
> > >
> > > 1. How do we decide which field/protocol takes precedence to define the
> packet input color? You are enabling 2 possible options so far, i.e. VLAN tag
> PCP field and IP DSCP field, which one is to be set for the current meter
> object? Using the capabilities to decide is confusing, as a specific meter
> object might be able to support multiple or even all the possible options (e.g.
> the meter object is fine with either IP DSCP or VLAN PCP). Therefore, we
> need a clear mechanism to unequivocally pick one; I think the user must
> explicitly define which input color methodology is to be used by explicitly
> setting a field (to be added) in the meter object parameter structure.
> >
> > Currently, in our HW, Each meter object needs to tell which pre-color
> > scheme it is going to use(IP DSCP or VLAN PCP). This is OK in the
> > overall scheme of things as the meter object is connected to rte_flow.
> > So,
> > rte_flow pattern can decide the steering to meter. Having said that,
> > it is possible to have array for input color as you suggested. If
> > choose that, path, We need to add capability tell implementation
> > supports only one input color per meter object. Let me know if this is
> > OK.
> >
Thanks for the explanation of the capabilities you are trying to enable in the API. Based on this, I am reconsidering some of my previous input. Here are my current thoughts:
a) Each meter object can be configured with multiple methods to determine the input color: IP DSCP and VLAN PCP are just two of them, others are possible (as also listed by you). I think the problem we are trying to solve here is: in case multiple such methods are enabled for a given meter object AND more than one enabled method is applicable for a particular input packet at run-time (e.g. the packet is an IP packet, but it also contains at least one VLAN label, and both IP DSCP and the VLAN PCP methods are enabled for the meter object), how do we decide which method is to be applied? So, IMO we need to define a priority scheme that always picks a single method:
- a unique priority for each method;
- a default method to be used when none of the enabled methods is applicable to the input packet.
b) The default method must be usable even when the input packet type is unknown to the HW (unsupported), e.g. we should still be able to decide the input color of a packet that is not an IP packet, such as ARP, and it does not contain any VLAN labels. For this, I suggest we add a field ins struct rte_mtr_params called default_input_color of type enum rte_color:
struct rte_mtr_params {
enum rte_color default_input_color; /* Input color to be set for the input packet when none of the enabled input color methods is applicable to the current input packet. Ignored when this method is set to the color blind method. */
};
c) In terms of methods and their priority, I propose to start with the following options, each of which referring to a set of methods, with a clear way to select a unique method. This is the minimal set needed to support the HW capabilities that you mention, this set can be extended as needed in the future:
enum rte_mtr_input_color_method {
RTE_MTR_INPUT_COLOR_METHOD_COLOR_BLIND, /* The input color is always green. The default_input_color is ignored for this method. */
RTE_ MTR_INPUT_COLOR_METHOD_IP_DSCP, /* If the input packet is IPv4 or IPv6, its input color is detected by the DSCP field indexing into the dscp_table. Otherwise, the default_input_color is applied. */
RTE_ MTR_INPUT_COLOR_METHOD_OUTER_VLAN_PCP, /* If the input packet has at least one VLAN label, its input color is detected by the outermost VLAN PCP indexing into the vlan_table. Otherwise, the default_input_color is applied. */
RTE_ MTR_INPUT_COLOR_METHOD_OUTER_VLAN_PCP_IP_DSCP, /* If the input packet has at least one VLAN label, its input color is detected by the outermost VLAN PCP indexing into the vlan_table. Otherwise, if the packet is IPv4 or IPv6, its input color is detected by the DSCP field indexing into the dscp_table. Otherwise, the default_input_color is applied. */
RTE_ MTR_INPUT_COLOR_METHOD_INNER_VLAN_PCP, /* If the input packet has at least one VLAN label, its input color is detected by the innermost VLAN PCP indexing into the vlan_table. Otherwise, the default_input_color is applied. */
RTE_ MTR_INPUT_COLOR_METHOD_INNER_VLAN_PCP_IP_DSCP, /* If the input packet has at least one VLAN label, its input color is detected by the innermost VLAN PCP indexing into the vlan_table. Otherwise, if the packet is IPv4 or IPv6, its input color is detected by the DSCP field indexing into the dscp_table. Otherwise, the default_input_color is applied. */
};
struct rte_mtr_params {
enum rte_mtr_input_color_method input_color_method;
};
d) The above point means that all the protocol dependent tables are independent of each other, so they can all exist at the same time, so we cannot put all of them into a union or a single unified input color translation table. In case any of these tables is enabled/required by the input color scheme, but it is set to NULL, it must automatically resolve to an "all-green" table (as it is already the case for the existing dscp_table).
struct rte_mtr_params {
enum rte_color *ip_dscp_table; /* Used when the IP DSCP input color method is selected for the current input packet. If set to NULL, it defaults to 64 elements of RTE_COLOR_GREEN. */
enum rte_color *vlan_table; /* Used when the outermost/innermost VLAN PCP input color method is selected for the current input packet. If set to NULL, it defaults to all elements being RTE_COLOR_GREEN. */
};
So many details to address in order to avoid any loopholes in this API, but I think this scheme is implementable and robust enough. What do you think?
> >
> > >
> > > 2. What if the defined input color methodology is not applicable to the
> current input packet? For example, the user selects VLAN PCP, but some or
> all of the input packets do not contain any VLAN labels?
> >
> > it picks the rte_mtr_params::fallback_input_color
> >
We likely need a more complex scheme, see above ;)
> > >
> > > 3. How do we manage the many packet fields that could be used as the
> key for the input color: outer IP DSCP, inner IP DSCP, VLAN 1st label, VLAN
> 2nd label, MPLS QoS, etc?
> > > - Approach A: Use an enumeration, like you propose, and we can add
> more in the future. Not ideal.
> > > - Approach B: Point to a protocol-agnostic packet field by defining the
> offset and mask of a 64-bit field. Advantage: we don't need to change the
> API every time we add a new option.
> >
> > No strong opinion on doing Approach B. I think, it may be overkill for
> > application and implementation to express. No strong opinion, If you
> > have a strong opinion on that, I will change that to v1. Let me know.
> >
I would love to have a protocol agnostic scheme, but I am OK to start with a simple scheme for now (if you can call the above scheme as being simple ;) )and revisit later on if needed.
> >
> > >
> > > 4. I suggest we use a unified input color table as opposed to one per
> protocol, i.e. rename the struct rte_mtr_params::dscp_table to
> color_in_table. The size of this table could be implicitly defined by the packet
> field type (in case of enum) or the field mask (in case of protocol-agnostic
> field offset and mask), as described above.
> >
> > Will do that. I thought not to do that just because, I don't want to
> > remove the existing dscp_table symbol.
> > Make sense to enable your suggestion.
> >
> > Let me know your views on Questions 1 and 3. I will send the next
> > version based on that.
> >
Based on the above comments, I no longer thing a unified such table would work.
> >
> >
> > >
> > > Regards,
> > > Cristian
Regards,
Cristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features
2021-12-07 18:00 ` Dumitrescu, Cristian
@ 2022-01-10 9:35 ` Jerin Jacob
0 siblings, 0 replies; 30+ messages in thread
From: Jerin Jacob @ 2022-01-10 9:35 UTC (permalink / raw)
To: Dumitrescu, Cristian
Cc: jerinj, Thomas Monjalon, Yigit, Ferruh, Andrew Rybchenko, dev,
arybchenko, lizh, ajit.khaparde, Singh, Jasvinder, matan,
ndabilpuram, skori, rkudurumalla
On Tue, Dec 7, 2021 at 11:52 PM Dumitrescu, Cristian
<cristian.dumitrescu@intel.com> wrote:
>
> HI Jerin,
Hi Chistian,
>
> Sorry for my delay. I am currently in vacation until the beginning on January 2022, so my response is slower than usual.
I was too on vacation.
>
> Thanks for the explanation of the capabilities you are trying to enable in the API. Based on this, I am reconsidering some of my previous input. Here are my current thoughts:
>
> a) Each meter object can be configured with multiple methods to determine the input color: IP DSCP and VLAN PCP are just two of them, others are possible (as also listed by you). I think the problem we are trying to solve here is: in case multiple such methods are enabled for a given meter object AND more than one enabled method is applicable for a particular input packet at run-time (e.g. the packet is an IP packet, but it also contains at least one VLAN label, and both IP DSCP and the VLAN PCP methods are enabled for the meter object), how do we decide which method is to be applied? So, IMO we need to define a priority scheme that always picks a single method:
>
> - a unique priority for each method;
>
> - a default method to be used when none of the enabled methods is applicable to the input packet.
>
> b) The default method must be usable even when the input packet type is unknown to the HW (unsupported), e.g. we should still be able to decide the input color of a packet that is not an IP packet, such as ARP, and it does not contain any VLAN labels. For this, I suggest we add a field ins struct rte_mtr_params called default_input_color of type enum rte_color:
>
> struct rte_mtr_params {
> enum rte_color default_input_color; /* Input color to be set for the input packet when none of the enabled input color methods is applicable to the current input packet. Ignored when this method is set to the color blind method. */
> };
>
> c) In terms of methods and their priority, I propose to start with the following options, each of which referring to a set of methods, with a clear way to select a unique method. This is the minimal set needed to support the HW capabilities that you mention, this set can be extended as needed in the future:
>
> enum rte_mtr_input_color_method {
> RTE_MTR_INPUT_COLOR_METHOD_COLOR_BLIND, /* The input color is always green. The default_input_color is ignored for this method. */
> RTE_ MTR_INPUT_COLOR_METHOD_IP_DSCP, /* If the input packet is IPv4 or IPv6, its input color is detected by the DSCP field indexing into the dscp_table. Otherwise, the default_input_color is applied. */
> RTE_ MTR_INPUT_COLOR_METHOD_OUTER_VLAN_PCP, /* If the input packet has at least one VLAN label, its input color is detected by the outermost VLAN PCP indexing into the vlan_table. Otherwise, the default_input_color is applied. */
> RTE_ MTR_INPUT_COLOR_METHOD_OUTER_VLAN_PCP_IP_DSCP, /* If the input packet has at least one VLAN label, its input color is detected by the outermost VLAN PCP indexing into the vlan_table. Otherwise, if the packet is IPv4 or IPv6, its input color is detected by the DSCP field indexing into the dscp_table. Otherwise, the default_input_color is applied. */
> RTE_ MTR_INPUT_COLOR_METHOD_INNER_VLAN_PCP, /* If the input packet has at least one VLAN label, its input color is detected by the innermost VLAN PCP indexing into the vlan_table. Otherwise, the default_input_color is applied. */
> RTE_ MTR_INPUT_COLOR_METHOD_INNER_VLAN_PCP_IP_DSCP, /* If the input packet has at least one VLAN label, its input color is detected by the innermost VLAN PCP indexing into the vlan_table. Otherwise, if the packet is IPv4 or IPv6, its input color is detected by the DSCP field indexing into the dscp_table. Otherwise, the default_input_color is applied. */
> };
>
> struct rte_mtr_params {
> enum rte_mtr_input_color_method input_color_method;
> };
>
> d) The above point means that all the protocol dependent tables are independent of each other, so they can all exist at the same time, so we cannot put all of them into a union or a single unified input color translation table. In case any of these tables is enabled/required by the input color scheme, but it is set to NULL, it must automatically resolve to an "all-green" table (as it is already the case for the existing dscp_table).
>
> struct rte_mtr_params {
> enum rte_color *ip_dscp_table; /* Used when the IP DSCP input color method is selected for the current input packet. If set to NULL, it defaults to 64 elements of RTE_COLOR_GREEN. */
> enum rte_color *vlan_table; /* Used when the outermost/innermost VLAN PCP input color method is selected for the current input packet. If set to NULL, it defaults to all elements being RTE_COLOR_GREEN. */
> };
>
> So many details to address in order to avoid any loopholes in this API, but I think this scheme is implementable and robust enough. What do you think?
Sounds good. I will next version based on your suggestion.
>
> > >
> > > >
> > > > 2. What if the defined input color methodology is not applicable to the
> > current input packet? For example, the user selects VLAN PCP, but some or
> > all of the input packets do not contain any VLAN labels?
> > >
> > > it picks the rte_mtr_params::fallback_input_color
> > >
>
> We likely need a more complex scheme, see above ;)
>
> > > >
> > > > 3. How do we manage the many packet fields that could be used as the
> > key for the input color: outer IP DSCP, inner IP DSCP, VLAN 1st label, VLAN
> > 2nd label, MPLS QoS, etc?
> > > > - Approach A: Use an enumeration, like you propose, and we can add
> > more in the future. Not ideal.
> > > > - Approach B: Point to a protocol-agnostic packet field by defining the
> > offset and mask of a 64-bit field. Advantage: we don't need to change the
> > API every time we add a new option.
> > >
> > > No strong opinion on doing Approach B. I think, it may be overkill for
> > > application and implementation to express. No strong opinion, If you
> > > have a strong opinion on that, I will change that to v1. Let me know.
> > >
>
> I would love to have a protocol agnostic scheme, but I am OK to start with a simple scheme for now (if you can call the above scheme as being simple ;) )and revisit later on if needed.
>
> > >
> > > >
> > > > 4. I suggest we use a unified input color table as opposed to one per
> > protocol, i.e. rename the struct rte_mtr_params::dscp_table to
> > color_in_table. The size of this table could be implicitly defined by the packet
> > field type (in case of enum) or the field mask (in case of protocol-agnostic
> > field offset and mask), as described above.
> > >
> > > Will do that. I thought not to do that just because, I don't want to
> > > remove the existing dscp_table symbol.
> > > Make sense to enable your suggestion.
> > >
> > > Let me know your views on Questions 1 and 3. I will send the next
> > > version based on that.
> > >
>
> Based on the above comments, I no longer thing a unified such table would work.
>
> > >
> > >
> > > >
> > > > Regards,
> > > > Cristian
>
> Regards,
> Cristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* [dpdk-dev] [v22.07] [PATCH] ethdev: mtr: support input color selection
2021-08-20 8:24 [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features jerinj
2021-08-30 9:23 ` Jerin Jacob
2021-10-11 15:14 ` Dumitrescu, Cristian
@ 2022-02-14 11:56 ` jerinj
2022-02-14 12:02 ` [dpdk-dev] [v22.07] [PATCH v2] " jerinj
2 siblings, 1 reply; 30+ messages in thread
From: jerinj @ 2022-02-14 11:56 UTC (permalink / raw)
To: dev, Cristian Dumitrescu, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko, Ray Kinsella
Cc: ajit.khaparde, aboyer, beilei.xing, bruce.richardson, chas3,
chenbo.xia, ciara.loftus, dsinghrawat, ed.czeck, evgenys, grive,
g.singh, zhouguoyang, haiyue.wang, hkalra, heinrich.kuhn,
hemant.agrawal, hyonkim, igorch, irusskikh, jgrajcia,
jasvinder.singh, jianwang, jiawenwu, jingjing.wu, johndale,
john.miller, linville, keith.wiles, kirankumark, oulijun, lironh,
longli, mw, spinler, matan, matt.peters, maxime.coquelin, mk,
humin29, pnalla, ndabilpuram, qiming.yang, qi.z.zhang, radhac,
rahul.lakkireddy, rmody, rosen.xu, sachin.saxena, skoteshwar,
shshaikh, shaibran, shepard.siegel, asomalap, somnath.kotur,
sthemmin, steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2, Jerin Jacob
From: Jerin Jacob <jerinj@marvell.com>
Currently, meter object supports only DSCP based on input color table,
The patch enhance that to support VLAN based input color table,
color table based on inner field for the tunnel use case, and support
for fallback color per meter if packet based on a different field.
All of the above features are exposed through capability and added
additional capability to specify the implementation supports
more than one input color table per ethdev port
Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---
v1..RFC:
Address the review comments by Cristian at
https://patches.dpdk.org/project/dpdk/patch/20210820082401.3778736-1-jerinj@marvell.com/
- Moved to v22.07 release
- Updated rte_mtr_input_color_method to support all VLAN, DSCP, Inner cases
- Added input_color_method
- Removed union between vlan_table and dscp_table
- Kept VLAN instead of PCP as HW coloring based on DEI(1bit), PCP(3 bits)
What is missing:
- 22.07 release notes update
- Testpmd and driver updates(Waiting for the review comments v1 API spec)
.../traffic_metering_and_policing.rst | 27 +++
lib/ethdev/rte_mtr.h | 162 +++++++++++++++++-
lib/ethdev/version.map | 3 +
3 files changed, 190 insertions(+), 2 deletions(-)
diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst
index ceb5a96488..97d27c92e3 100644
--- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
+++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
@@ -21,6 +21,7 @@ The main features are:
* Policer actions (per meter output color): recolor, drop
* Statistics (per policer output color)
* Chaining multiple meter objects
+* Packet content based input color selection
Configuration steps
-------------------
@@ -105,3 +106,29 @@ traffic meter and policing library.
* Adding one (or multiple) actions of the type ``RTE_FLOW_ACTION_TYPE_METER``
to the list of meter actions (``struct rte_mtr_meter_policy_params::actions``)
specified per color as show in :numref:`figure_rte_mtr_chaining`.
+
+Packet content based input color selection
+------------------------------------------
+
+The API supports selecting the input color based on the packet content.
+Following is the API usage model for the same.
+
+#. Probe the input color selection device capabilities using following
+ parameter using ``rte_mtr_capabilities_get()`` API
+ ``struct rte_mtr_capabilities::rte_mtr_input_color_method`` and
+ ``struct rte_mtr_capabilitie::seperate_input_color_table_per_port``
+#. When creating the meter object using ``rte_mtr_create()``, configure
+ relevant input color selection parameters such as
+
+ * Select the input color method ``struct rte_mtr_params::input_color_method``
+
+ * Fill the tables ``struct rte_mtr_params::dscp_table``,
+ ``struct rte_mtr_params::dscp_table`` based on input color selected
+
+ * Update the ``struct rte_mtr_params::default_input_color`` to determine
+ the default input color in case the input packet does not match
+ the input color method
+
+ * If needed, update the input color table at runtime using
+ ``rte_mtr_meter_vlan_table_update()`` and ``rte_mtr_meter_dscp_table_update()``
+ APIs.
diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h
index 40df0888c8..3caea823ad 100644
--- a/lib/ethdev/rte_mtr.h
+++ b/lib/ethdev/rte_mtr.h
@@ -213,6 +213,80 @@ struct rte_mtr_meter_policy_params {
const struct rte_flow_action *actions[RTE_COLORS];
};
+/**
+ * Input color method
+ */
+enum rte_mtr_input_color_method {
+ /**
+ * The input color is always green.
+ * The default_input_color is ignored for this method.
+ * @see struct rte_mtr_params::default_input_color
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_COLOR_BLIND,
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_VLAN,
+ /**
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the outermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_DSCP,
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the outermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP,
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN,
+ /**
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the innermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_INNER_DSCP,
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the innermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP,
+};
+
/**
* Parameters for each traffic metering & policing object
*
@@ -233,7 +307,15 @@ struct rte_mtr_params {
*/
int use_prev_mtr_color;
- /** Meter input color. When non-NULL: it points to a pre-allocated and
+ /** Meter input color based on IP DSCP field.
+ *
+ * Valid when input_color_method set to any of the following
+ * RTE_MTR_INPUT_COLOR_METHOD_DSCP,
+ * RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP,
+ * RTE_MTR_INPUT_COLOR_METHOD_INNER_DSCP,
+ * RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP
+ *
+ * When non-NULL: it points to a pre-allocated and
* pre-populated table with exactly 64 elements providing the input
* color for each value of the IPv4/IPv6 Differentiated Services Code
* Point (DSCP) input packet field. When NULL: it is equivalent to
@@ -244,9 +326,39 @@ struct rte_mtr_params {
* *use_prev_mtr_color* is non-zero value or when *dscp_table* contains
* at least one yellow or red color element, then the color aware mode
* is configured.
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_DSCP
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_DSCP
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP
+ * @see struct rte_mtr_params::input_color_method
*/
enum rte_color *dscp_table;
-
+ /** Meter input color based on VLAN DEI(1bit), PCP(3 bits) fields.
+ *
+ * Valid when input_color_method set to any of the following
+ * RTE_MTR_INPUT_COLOR_METHOD_VLAN,
+ * RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP,
+ * RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN,
+ * RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP
+ *
+ * When non-NULL: it points to a pre-allocated and pre-populated
+ * table with exactly 16 elements providing the input color for
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ * When NULL: it is equivalent to setting this parameter to an
+ * all-green populated table (i.e. table with
+ * all the 16 elements set to green color). The color blind mode
+ * is configured by setting *use_prev_mtr_color* to 0 and
+ * *vlan_table* to either NULL or to an all-green
+ * populated table. When *use_prev_mtr_color* is non-zero value
+ * or when *vlan_table* contains at least one yellow or
+ * red color element, then the color aware mode is configured.
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_VLAN
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP
+ * @see struct rte_mtr_params::input_color_method
+ */
+ enum rte_color *vlan_table;
/** Non-zero to enable the meter, zero to disable the meter at the time
* of MTR object creation. Ignored when the meter profile indicated by
* *meter_profile_id* is set to NONE.
@@ -261,6 +373,20 @@ struct rte_mtr_params {
/** Meter policy ID. @see rte_mtr_meter_policy_add() */
uint32_t meter_policy_id;
+
+ /** Input color method to select.
+ * @see struct rte_mtr_params::dscp_table
+ * @see struct rte_mtr_params::vlan_table
+ */
+ enum rte_mtr_input_color_method input_color_method;
+
+ /** Input color to be set for the input packet when none of the
+ * enabled input color methods is applicable to the input packet.
+ * Ignored when this method is set to the
+ * enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_COLOR_BLIND
+ * method.
+ */
+ enum rte_color default_input_color;
};
/**
@@ -417,6 +543,14 @@ struct rte_mtr_capabilities {
* @see enum rte_mtr_stats_type
*/
uint64_t stats_mask;
+
+ /** Input color methods supported. */
+ enum rte_mtr_input_color_method methods_supported;
+
+ /** When non-zero, it indicates that driver supports separate
+ * input color table for given ethdev port.
+ */
+ int seperate_input_color_table_per_port;
};
/**
@@ -832,6 +966,30 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
enum rte_color *dscp_table,
struct rte_mtr_error *error);
+/**
+ * MTR object VLAN table update
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[in] vlan_table
+ * When non-NULL: it points to a pre-allocated and pre-populated table with
+ * exactly 16 elements providing the input color for each value of the
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ * When NULL: it is equivalent to setting this parameter to an "all-green"
+ * populated table (i.e. table with all the 16 elements set to green color).
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+__rte_experimental
+int
+rte_mtr_meter_vlan_table_update(uint16_t port_id,
+ uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error);
/**
* MTR object enabled statistics counters update
*
diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
index d5cc56a560..430c620490 100644
--- a/lib/ethdev/version.map
+++ b/lib/ethdev/version.map
@@ -264,6 +264,9 @@ EXPERIMENTAL {
rte_eth_ip_reassembly_capability_get;
rte_eth_ip_reassembly_conf_get;
rte_eth_ip_reassembly_conf_set;
+
+ # added in 22.07
+ rte_mtr_meter_vlan_table_update;
};
INTERNAL {
--
2.35.1
^ permalink raw reply [flat|nested] 30+ messages in thread
* [dpdk-dev] [v22.07] [PATCH v2] ethdev: mtr: support input color selection
2022-02-14 11:56 ` [dpdk-dev] [v22.07] [PATCH] ethdev: mtr: support input color selection jerinj
@ 2022-02-14 12:02 ` jerinj
2022-03-01 8:58 ` [PATCH v3 1/1] " skori
0 siblings, 1 reply; 30+ messages in thread
From: jerinj @ 2022-02-14 12:02 UTC (permalink / raw)
To: dev, Cristian Dumitrescu, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko, Ray Kinsella
Cc: ajit.khaparde, aboyer, beilei.xing, bruce.richardson, chas3,
chenbo.xia, ciara.loftus, dsinghrawat, ed.czeck, evgenys, grive,
g.singh, zhouguoyang, haiyue.wang, hkalra, heinrich.kuhn,
hemant.agrawal, hyonkim, igorch, irusskikh, jgrajcia,
jasvinder.singh, jianwang, jiawenwu, jingjing.wu, johndale,
john.miller, linville, keith.wiles, kirankumark, oulijun, lironh,
longli, mw, spinler, matan, matt.peters, maxime.coquelin, mk,
humin29, pnalla, ndabilpuram, qiming.yang, qi.z.zhang, radhac,
rahul.lakkireddy, rmody, rosen.xu, sachin.saxena, skoteshwar,
shshaikh, shaibran, shepard.siegel, asomalap, somnath.kotur,
sthemmin, steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2, Jerin Jacob
From: Jerin Jacob <jerinj@marvell.com>
Currently, meter object supports only DSCP based on input color table,
The patch enhance that to support VLAN based input color table,
color table based on inner field for the tunnel use case, and support
for fallback color per meter if packet based on a different field.
All of the above features are exposed through capability and added
additional capability to specify the implementation supports
more than one input color table per ethdev port
Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---
v2..v1:
- Fix seperate typo
v1..RFC:
Address the review comments by Cristian at
https://patches.dpdk.org/project/dpdk/patch/20210820082401.3778736-1-jerinj@marvell.com/
- Moved to v22.07 release
- Updated rte_mtr_input_color_method to support all VLAN, DSCP, Inner cases
- Added input_color_method
- Removed union between vlan_table and dscp_table
- Kept VLAN instead of PCP as HW coloring based on DEI(1bit), PCP(3 bits)
What is missing:
- 22.07 release notes update
- Testpmd and driver updates(Waiting for the review comments v1 API spec)
.../traffic_metering_and_policing.rst | 27 +++
lib/ethdev/rte_mtr.h | 162 +++++++++++++++++-
lib/ethdev/version.map | 3 +
3 files changed, 190 insertions(+), 2 deletions(-)
diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst
index ceb5a96488..db8113f635 100644
--- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
+++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
@@ -21,6 +21,7 @@ The main features are:
* Policer actions (per meter output color): recolor, drop
* Statistics (per policer output color)
* Chaining multiple meter objects
+* Packet content based input color selection
Configuration steps
-------------------
@@ -105,3 +106,29 @@ traffic meter and policing library.
* Adding one (or multiple) actions of the type ``RTE_FLOW_ACTION_TYPE_METER``
to the list of meter actions (``struct rte_mtr_meter_policy_params::actions``)
specified per color as show in :numref:`figure_rte_mtr_chaining`.
+
+Packet content based input color selection
+------------------------------------------
+
+The API supports selecting the input color based on the packet content.
+Following is the API usage model for the same.
+
+#. Probe the input color selection device capabilities using following
+ parameter using ``rte_mtr_capabilities_get()`` API
+ ``struct rte_mtr_capabilities::rte_mtr_input_color_method`` and
+ ``struct rte_mtr_capabilitie::separate_input_color_table_per_port``
+#. When creating the meter object using ``rte_mtr_create()``, configure
+ relevant input color selection parameters such as
+
+ * Select the input color method ``struct rte_mtr_params::input_color_method``
+
+ * Fill the tables ``struct rte_mtr_params::dscp_table``,
+ ``struct rte_mtr_params::dscp_table`` based on input color selected
+
+ * Update the ``struct rte_mtr_params::default_input_color`` to determine
+ the default input color in case the input packet does not match
+ the input color method
+
+ * If needed, update the input color table at runtime using
+ ``rte_mtr_meter_vlan_table_update()`` and ``rte_mtr_meter_dscp_table_update()``
+ APIs.
diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h
index 40df0888c8..ced8bfb491 100644
--- a/lib/ethdev/rte_mtr.h
+++ b/lib/ethdev/rte_mtr.h
@@ -213,6 +213,80 @@ struct rte_mtr_meter_policy_params {
const struct rte_flow_action *actions[RTE_COLORS];
};
+/**
+ * Input color method
+ */
+enum rte_mtr_input_color_method {
+ /**
+ * The input color is always green.
+ * The default_input_color is ignored for this method.
+ * @see struct rte_mtr_params::default_input_color
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_COLOR_BLIND,
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_VLAN,
+ /**
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the outermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_DSCP,
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the outermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP,
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN,
+ /**
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the innermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_INNER_DSCP,
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the innermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP,
+};
+
/**
* Parameters for each traffic metering & policing object
*
@@ -233,7 +307,15 @@ struct rte_mtr_params {
*/
int use_prev_mtr_color;
- /** Meter input color. When non-NULL: it points to a pre-allocated and
+ /** Meter input color based on IP DSCP field.
+ *
+ * Valid when input_color_method set to any of the following
+ * RTE_MTR_INPUT_COLOR_METHOD_DSCP,
+ * RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP,
+ * RTE_MTR_INPUT_COLOR_METHOD_INNER_DSCP,
+ * RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP
+ *
+ * When non-NULL: it points to a pre-allocated and
* pre-populated table with exactly 64 elements providing the input
* color for each value of the IPv4/IPv6 Differentiated Services Code
* Point (DSCP) input packet field. When NULL: it is equivalent to
@@ -244,9 +326,39 @@ struct rte_mtr_params {
* *use_prev_mtr_color* is non-zero value or when *dscp_table* contains
* at least one yellow or red color element, then the color aware mode
* is configured.
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_DSCP
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_DSCP
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP
+ * @see struct rte_mtr_params::input_color_method
*/
enum rte_color *dscp_table;
-
+ /** Meter input color based on VLAN DEI(1bit), PCP(3 bits) fields.
+ *
+ * Valid when input_color_method set to any of the following
+ * RTE_MTR_INPUT_COLOR_METHOD_VLAN,
+ * RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP,
+ * RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN,
+ * RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP
+ *
+ * When non-NULL: it points to a pre-allocated and pre-populated
+ * table with exactly 16 elements providing the input color for
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ * When NULL: it is equivalent to setting this parameter to an
+ * all-green populated table (i.e. table with
+ * all the 16 elements set to green color). The color blind mode
+ * is configured by setting *use_prev_mtr_color* to 0 and
+ * *vlan_table* to either NULL or to an all-green
+ * populated table. When *use_prev_mtr_color* is non-zero value
+ * or when *vlan_table* contains at least one yellow or
+ * red color element, then the color aware mode is configured.
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_VLAN
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP
+ * @see struct rte_mtr_params::input_color_method
+ */
+ enum rte_color *vlan_table;
/** Non-zero to enable the meter, zero to disable the meter at the time
* of MTR object creation. Ignored when the meter profile indicated by
* *meter_profile_id* is set to NONE.
@@ -261,6 +373,20 @@ struct rte_mtr_params {
/** Meter policy ID. @see rte_mtr_meter_policy_add() */
uint32_t meter_policy_id;
+
+ /** Input color method to select.
+ * @see struct rte_mtr_params::dscp_table
+ * @see struct rte_mtr_params::vlan_table
+ */
+ enum rte_mtr_input_color_method input_color_method;
+
+ /** Input color to be set for the input packet when none of the
+ * enabled input color methods is applicable to the input packet.
+ * Ignored when this method is set to the
+ * enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_COLOR_BLIND
+ * method.
+ */
+ enum rte_color default_input_color;
};
/**
@@ -417,6 +543,14 @@ struct rte_mtr_capabilities {
* @see enum rte_mtr_stats_type
*/
uint64_t stats_mask;
+
+ /** Input color methods supported. */
+ enum rte_mtr_input_color_method methods_supported;
+
+ /** When non-zero, it indicates that driver supports separate
+ * input color table for given ethdev port.
+ */
+ int separate_input_color_table_per_port;
};
/**
@@ -832,6 +966,30 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
enum rte_color *dscp_table,
struct rte_mtr_error *error);
+/**
+ * MTR object VLAN table update
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[in] vlan_table
+ * When non-NULL: it points to a pre-allocated and pre-populated table with
+ * exactly 16 elements providing the input color for each value of the
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ * When NULL: it is equivalent to setting this parameter to an "all-green"
+ * populated table (i.e. table with all the 16 elements set to green color).
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+__rte_experimental
+int
+rte_mtr_meter_vlan_table_update(uint16_t port_id,
+ uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error);
/**
* MTR object enabled statistics counters update
*
diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
index d5cc56a560..430c620490 100644
--- a/lib/ethdev/version.map
+++ b/lib/ethdev/version.map
@@ -264,6 +264,9 @@ EXPERIMENTAL {
rte_eth_ip_reassembly_capability_get;
rte_eth_ip_reassembly_conf_get;
rte_eth_ip_reassembly_conf_set;
+
+ # added in 22.07
+ rte_mtr_meter_vlan_table_update;
};
INTERNAL {
--
2.35.1
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v3 1/1] ethdev: mtr: support input color selection
2022-02-14 12:02 ` [dpdk-dev] [v22.07] [PATCH v2] " jerinj
@ 2022-03-01 8:58 ` skori
2022-03-01 10:49 ` [EXT] " Sunil Kumar Kori
` (2 more replies)
0 siblings, 3 replies; 30+ messages in thread
From: skori @ 2022-03-01 8:58 UTC (permalink / raw)
To: Cristian Dumitrescu, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko, Ray Kinsella
Cc: dev, Jerin Jacob
From: Jerin Jacob <jerinj@marvell.com>
Currently, meter object supports only DSCP based on input color table,
The patch enhance that to support VLAN based input color table,
color table based on inner field for the tunnel use case, and support
for fallback color per meter if packet based on a different field.
All of the above features are exposed through capability and added
additional capability to specify the implementation supports
more than one input color table per ethdev port
Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---
v3..v2:
- Fix input color flags as a bitmask
- Add definitions for newly added API
v2..v1:
- Fix seperate typo
v1..RFC:
Address the review comments by Cristian at
https://patches.dpdk.org/project/dpdk/patch/20210820082401.3778736-1-jerinj@marvell.com/
- Moved to v22.07 release
- Updated rte_mtr_input_color_method to support all VLAN, DSCP, Inner cases
- Added input_color_method
- Removed union between vlan_table and dscp_table
- Kept VLAN instead of PCP as HW coloring based on DEI(1bit), PCP(3 bits)
What is missing:
- 22.07 release notes update
.../traffic_metering_and_policing.rst | 28 +++
lib/ethdev/rte_mtr.c | 12 ++
lib/ethdev/rte_mtr.h | 164 +++++++++++++++++-
lib/ethdev/rte_mtr_driver.h | 9 +
lib/ethdev/version.map | 3 +
5 files changed, 214 insertions(+), 2 deletions(-)
diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst
index ceb5a96488..59ebd361ba 100644
--- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
+++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
@@ -21,6 +21,7 @@ The main features are:
* Policer actions (per meter output color): recolor, drop
* Statistics (per policer output color)
* Chaining multiple meter objects
+* Packet content based input color selection
Configuration steps
-------------------
@@ -105,3 +106,30 @@ traffic meter and policing library.
* Adding one (or multiple) actions of the type ``RTE_FLOW_ACTION_TYPE_METER``
to the list of meter actions (``struct rte_mtr_meter_policy_params::actions``)
specified per color as show in :numref:`figure_rte_mtr_chaining`.
+
+Packet content based input color selection
+------------------------------------------
+
+The API supports selecting the input color based on the packet content.
+Following is the API usage model for the same.
+
+#. Probe the input color selection device capabilities using following
+ parameter using ``rte_mtr_capabilities_get()`` API
+ ``struct rte_mtr_capabilities::methods_mask`` and
+ ``struct rte_mtr_capabilitie::separate_input_color_table_per_port``
+
+#. When creating the meter object using ``rte_mtr_create()``, configure
+ relevant input color selection parameters such as
+
+ * Select the input color method ``struct rte_mtr_params::input_color_method``
+
+ * Fill the tables ``struct rte_mtr_params::dscp_table``,
+ ``struct rte_mtr_params::dscp_table`` based on input color selected
+
+ * Update the ``struct rte_mtr_params::default_input_color`` to determine
+ the default input color in case the input packet does not match
+ the input color method
+
+ * If needed, update the input color table at runtime using
+ ``rte_mtr_meter_vlan_table_update()`` and ``rte_mtr_meter_dscp_table_update()``
+ APIs.
diff --git a/lib/ethdev/rte_mtr.c b/lib/ethdev/rte_mtr.c
index e49fcf271c..a0cb91e0b1 100644
--- a/lib/ethdev/rte_mtr.c
+++ b/lib/ethdev/rte_mtr.c
@@ -207,6 +207,18 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
mtr_id, dscp_table, error);
}
+/** MTR object meter VLAN table update */
+int
+rte_mtr_meter_vlan_table_update(uint16_t port_id,
+ uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ return RTE_MTR_FUNC(port_id, meter_vlan_table_update)(dev,
+ mtr_id, vlan_table, error);
+}
+
/** MTR object enabled stats update */
int
rte_mtr_stats_update(uint16_t port_id,
diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h
index 40df0888c8..7f9abebb41 100644
--- a/lib/ethdev/rte_mtr.h
+++ b/lib/ethdev/rte_mtr.h
@@ -213,6 +213,80 @@ struct rte_mtr_meter_policy_params {
const struct rte_flow_action *actions[RTE_COLORS];
};
+/**
+ * Input color method
+ */
+enum rte_mtr_input_color_method {
+ /**
+ * The input color is always green.
+ * The default_input_color is ignored for this method.
+ * @see struct rte_mtr_params::default_input_color
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_COLOR_BLIND = RTE_BIT64(0),
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_VLAN = RTE_BIT64(1),
+ /**
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the outermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_DSCP = RTE_BIT64(2),
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the outermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP = RTE_BIT64(3),
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN = RTE_BIT64(4),
+ /**
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the innermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_INNER_DSCP = RTE_BIT64(5),
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the innermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the default_input_color is applied.
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP = RTE_BIT64(6),
+};
+
/**
* Parameters for each traffic metering & policing object
*
@@ -233,7 +307,15 @@ struct rte_mtr_params {
*/
int use_prev_mtr_color;
- /** Meter input color. When non-NULL: it points to a pre-allocated and
+ /** Meter input color based on IP DSCP field.
+ *
+ * Valid when input_color_method set to any of the following
+ * RTE_MTR_INPUT_COLOR_METHOD_DSCP,
+ * RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP,
+ * RTE_MTR_INPUT_COLOR_METHOD_INNER_DSCP,
+ * RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP
+ *
+ * When non-NULL: it points to a pre-allocated and
* pre-populated table with exactly 64 elements providing the input
* color for each value of the IPv4/IPv6 Differentiated Services Code
* Point (DSCP) input packet field. When NULL: it is equivalent to
@@ -244,9 +326,39 @@ struct rte_mtr_params {
* *use_prev_mtr_color* is non-zero value or when *dscp_table* contains
* at least one yellow or red color element, then the color aware mode
* is configured.
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_DSCP
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_DSCP
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP
+ * @see struct rte_mtr_params::input_color_method
*/
enum rte_color *dscp_table;
-
+ /** Meter input color based on VLAN DEI(1bit), PCP(3 bits) fields.
+ *
+ * Valid when input_color_method set to any of the following
+ * RTE_MTR_INPUT_COLOR_METHOD_VLAN,
+ * RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP,
+ * RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN,
+ * RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP
+ *
+ * When non-NULL: it points to a pre-allocated and pre-populated
+ * table with exactly 16 elements providing the input color for
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ * When NULL: it is equivalent to setting this parameter to an
+ * all-green populated table (i.e. table with
+ * all the 16 elements set to green color). The color blind mode
+ * is configured by setting *use_prev_mtr_color* to 0 and
+ * *vlan_table* to either NULL or to an all-green
+ * populated table. When *use_prev_mtr_color* is non-zero value
+ * or when *vlan_table* contains at least one yellow or
+ * red color element, then the color aware mode is configured.
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_VLAN
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN
+ * @see enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP
+ * @see struct rte_mtr_params::input_color_method
+ */
+ enum rte_color *vlan_table;
/** Non-zero to enable the meter, zero to disable the meter at the time
* of MTR object creation. Ignored when the meter profile indicated by
* *meter_profile_id* is set to NONE.
@@ -261,6 +373,20 @@ struct rte_mtr_params {
/** Meter policy ID. @see rte_mtr_meter_policy_add() */
uint32_t meter_policy_id;
+
+ /** Input color method to select.
+ * @see struct rte_mtr_params::dscp_table
+ * @see struct rte_mtr_params::vlan_table
+ */
+ enum rte_mtr_input_color_method input_color_method;
+
+ /** Input color to be set for the input packet when none of the
+ * enabled input color methods is applicable to the input packet.
+ * Ignored when this method is set to the
+ * enum rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_COLOR_BLIND
+ * method.
+ */
+ enum rte_color default_input_color;
};
/**
@@ -417,6 +543,16 @@ struct rte_mtr_capabilities {
* @see enum rte_mtr_stats_type
*/
uint64_t stats_mask;
+
+ /** Set of supported input color methods.
+ * @see enum rte_mtr_input_color_method
+ */
+ uint64_t methods_mask;
+
+ /** When non-zero, it indicates that driver supports separate
+ * input color table for given ethdev port.
+ */
+ int separate_input_color_table_per_port;
};
/**
@@ -832,6 +968,30 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
enum rte_color *dscp_table,
struct rte_mtr_error *error);
+/**
+ * MTR object VLAN table update
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[in] vlan_table
+ * When non-NULL: it points to a pre-allocated and pre-populated table with
+ * exactly 16 elements providing the input color for each value of the
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ * When NULL: it is equivalent to setting this parameter to an "all-green"
+ * populated table (i.e. table with all the 16 elements set to green color).
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+__rte_experimental
+int
+rte_mtr_meter_vlan_table_update(uint16_t port_id,
+ uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error);
/**
* MTR object enabled statistics counters update
*
diff --git a/lib/ethdev/rte_mtr_driver.h b/lib/ethdev/rte_mtr_driver.h
index ee8c6ef7ad..37ab79666b 100644
--- a/lib/ethdev/rte_mtr_driver.h
+++ b/lib/ethdev/rte_mtr_driver.h
@@ -97,6 +97,12 @@ typedef int (*rte_mtr_meter_dscp_table_update_t)(struct rte_eth_dev *dev,
enum rte_color *dscp_table,
struct rte_mtr_error *error);
+/** @internal MTR object meter VLAN table update. */
+typedef int (*rte_mtr_meter_vlan_table_update_t)(struct rte_eth_dev *dev,
+ uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error);
+
/** @internal MTR object enabled stats update. */
typedef int (*rte_mtr_stats_update_t)(struct rte_eth_dev *dev,
uint32_t mtr_id,
@@ -139,6 +145,9 @@ struct rte_mtr_ops {
/** MTR object meter DSCP table update */
rte_mtr_meter_dscp_table_update_t meter_dscp_table_update;
+ /** MTR object meter VLAN table update */
+ rte_mtr_meter_vlan_table_update_t meter_vlan_table_update;
+
/** MTR object enabled stats update */
rte_mtr_stats_update_t stats_update;
diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
index 20391ab29e..77915c0ddc 100644
--- a/lib/ethdev/version.map
+++ b/lib/ethdev/version.map
@@ -279,6 +279,9 @@ EXPERIMENTAL {
rte_flow_async_action_handle_create;
rte_flow_async_action_handle_destroy;
rte_flow_async_action_handle_update;
+
+ # added in 22.07
+ rte_mtr_meter_vlan_table_update;
};
INTERNAL {
--
2.25.1
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [EXT] [PATCH v3 1/1] ethdev: mtr: support input color selection
2022-03-01 8:58 ` [PATCH v3 1/1] " skori
@ 2022-03-01 10:49 ` Sunil Kumar Kori
2022-03-01 17:48 ` Dumitrescu, Cristian
2022-04-21 18:02 ` [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based " jerinj
2 siblings, 0 replies; 30+ messages in thread
From: Sunil Kumar Kori @ 2022-03-01 10:49 UTC (permalink / raw)
To: Sunil Kumar Kori, Cristian Dumitrescu, Thomas Monjalon,
Ferruh Yigit, Andrew Rybchenko, Ray Kinsella
Cc: dev, Jerin Jacob Kollanukkaran
Corresponding driver implementation is available at http://patches.dpdk.org/project/dpdk/patch/20220301090056.1042866-1-skori@marvell.com/.
Also CLI is added to testpmd for below API and available at http://patches.dpdk.org/project/dpdk/patch/20220301090056.1042866-3-skori@marvell.com/
> -----Original Message-----
> From: skori@marvell.com <skori@marvell.com>
> Sent: Tuesday, March 1, 2022 2:28 PM
> To: Cristian Dumitrescu <cristian.dumitrescu@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>; Andrew
> Rybchenko <andrew.rybchenko@oktetlabs.ru>; Ray Kinsella
> <mdr@ashroe.eu>
> Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Subject: [EXT] [PATCH v3 1/1] ethdev: mtr: support input color selection
>
> External Email
>
> ----------------------------------------------------------------------
> From: Jerin Jacob <jerinj@marvell.com>
>
> Currently, meter object supports only DSCP based on input color table, The
> patch enhance that to support VLAN based input color table, color table
> based on inner field for the tunnel use case, and support for fallback color
> per meter if packet based on a different field.
>
> All of the above features are exposed through capability and added
> additional capability to specify the implementation supports more than one
> input color table per ethdev port
>
> Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> ---
> v3..v2:
> - Fix input color flags as a bitmask
> - Add definitions for newly added API
>
> v2..v1:
>
> - Fix seperate typo
>
> v1..RFC:
>
> Address the review comments by Cristian at
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__patches.dpdk.org_project_dpdk_patch_20210820082401.3778736-2D1-
> 2Djerinj-
> 40marvell.com_&d=DwIDAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=dXeXaAMkP5
> COgn1zxHMyaF1_d9IIuq6vHQO6NrIPjaE&m=bvYbz6aP4xuLPRt2TIk1o99kWXj
> u-rRDvz3qXnCVbz_TER0zcRDqjQxJSm3SnLXM&s=mVeBbQWjsvJLRm-dcB4h-
> KmAj3tGi4WT0E9IvsuNT2g&e=
>
> - Moved to v22.07 release
> - Updated rte_mtr_input_color_method to support all VLAN, DSCP, Inner
> cases
> - Added input_color_method
> - Removed union between vlan_table and dscp_table
> - Kept VLAN instead of PCP as HW coloring based on DEI(1bit), PCP(3 bits)
>
> What is missing:
> - 22.07 release notes update
>
> .../traffic_metering_and_policing.rst | 28 +++
> lib/ethdev/rte_mtr.c | 12 ++
> lib/ethdev/rte_mtr.h | 164 +++++++++++++++++-
> lib/ethdev/rte_mtr_driver.h | 9 +
> lib/ethdev/version.map | 3 +
> 5 files changed, 214 insertions(+), 2 deletions(-)
>
> diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst
> b/doc/guides/prog_guide/traffic_metering_and_policing.rst
> index ceb5a96488..59ebd361ba 100644
> --- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
> +++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
> @@ -21,6 +21,7 @@ The main features are:
> * Policer actions (per meter output color): recolor, drop
> * Statistics (per policer output color)
> * Chaining multiple meter objects
> +* Packet content based input color selection
>
> Configuration steps
> -------------------
> @@ -105,3 +106,30 @@ traffic meter and policing library.
> * Adding one (or multiple) actions of the type
> ``RTE_FLOW_ACTION_TYPE_METER``
> to the list of meter actions (``struct
> rte_mtr_meter_policy_params::actions``)
> specified per color as show in :numref:`figure_rte_mtr_chaining`.
> +
> +Packet content based input color selection
> +------------------------------------------
> +
> +The API supports selecting the input color based on the packet content.
> +Following is the API usage model for the same.
> +
> +#. Probe the input color selection device capabilities using following
> + parameter using ``rte_mtr_capabilities_get()`` API
> + ``struct rte_mtr_capabilities::methods_mask`` and
> + ``struct rte_mtr_capabilitie::separate_input_color_table_per_port``
> +
> +#. When creating the meter object using ``rte_mtr_create()``, configure
> + relevant input color selection parameters such as
> +
> + * Select the input color method ``struct
> + rte_mtr_params::input_color_method``
> +
> + * Fill the tables ``struct rte_mtr_params::dscp_table``,
> + ``struct rte_mtr_params::dscp_table`` based on input color
> + selected
> +
> + * Update the ``struct rte_mtr_params::default_input_color`` to determine
> + the default input color in case the input packet does not match
> + the input color method
> +
> + * If needed, update the input color table at runtime using
> + ``rte_mtr_meter_vlan_table_update()`` and
> ``rte_mtr_meter_dscp_table_update()``
> + APIs.
> diff --git a/lib/ethdev/rte_mtr.c b/lib/ethdev/rte_mtr.c index
> e49fcf271c..a0cb91e0b1 100644
> --- a/lib/ethdev/rte_mtr.c
> +++ b/lib/ethdev/rte_mtr.c
> @@ -207,6 +207,18 @@ rte_mtr_meter_dscp_table_update(uint16_t
> port_id,
> mtr_id, dscp_table, error);
> }
>
> +/** MTR object meter VLAN table update */ int
> +rte_mtr_meter_vlan_table_update(uint16_t port_id,
> + uint32_t mtr_id,
> + enum rte_color *vlan_table,
> + struct rte_mtr_error *error)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + return RTE_MTR_FUNC(port_id, meter_vlan_table_update)(dev,
> + mtr_id, vlan_table, error);
> +}
> +
> /** MTR object enabled stats update */
> int
> rte_mtr_stats_update(uint16_t port_id,
> diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h index
> 40df0888c8..7f9abebb41 100644
> --- a/lib/ethdev/rte_mtr.h
> +++ b/lib/ethdev/rte_mtr.h
> @@ -213,6 +213,80 @@ struct rte_mtr_meter_policy_params {
> const struct rte_flow_action *actions[RTE_COLORS]; };
>
> +/**
> + * Input color method
> + */
> +enum rte_mtr_input_color_method {
> + /**
> + * The input color is always green.
> + * The default_input_color is ignored for this method.
> + * @see struct rte_mtr_params::default_input_color
> + */
> + RTE_MTR_INPUT_COLOR_METHOD_COLOR_BLIND = RTE_BIT64(0),
> + /**
> + * If the input packet has at least one VLAN label, its input color is
> + * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
> + * indexing into the struct rte_mtr_params::vlan_table.
> + * Otherwise, the default_input_color is applied.
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::vlan_table
> + */
> + RTE_MTR_INPUT_COLOR_METHOD_VLAN = RTE_BIT64(1),
> + /**
> + * If the input packet is IPv4 or IPv6, its input color is detected by
> + * the outermost DSCP field indexing into the
> + * struct rte_mtr_params::dscp_table.
> + * Otherwise, the default_input_color is applied.
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::dscp_table
> + */
> + RTE_MTR_INPUT_COLOR_METHOD_DSCP = RTE_BIT64(2),
> + /**
> + * If the input packet has at least one VLAN label, its input color is
> + * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
> + * indexing into the struct rte_mtr_params::vlan_table.
> + * If the input packet is IPv4 or IPv6, its input color is detected by
> + * the outermost DSCP field indexing into the
> + * struct rte_mtr_params::dscp_table.
> + * Otherwise, the default_input_color is applied.
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::vlan_table
> + * @see struct rte_mtr_params::dscp_table
> + */
> + RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP = RTE_BIT64(3),
> + /**
> + * If the input packet has at least one VLAN label, its input color is
> + * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
> + * indexing into the struct rte_mtr_params::vlan_table.
> + * Otherwise, the default_input_color is applied.
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::vlan_table
> + */
> + RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN = RTE_BIT64(4),
> + /**
> + * If the input packet is IPv4 or IPv6, its input color is detected by
> + * the innermost DSCP field indexing into the
> + * struct rte_mtr_params::dscp_table.
> + * Otherwise, the default_input_color is applied.
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::dscp_table
> + */
> + RTE_MTR_INPUT_COLOR_METHOD_INNER_DSCP = RTE_BIT64(5),
> + /**
> + * If the input packet has at least one VLAN label, its input color is
> + * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
> + * indexing into the struct rte_mtr_params::vlan_table.
> + * If the input packet is IPv4 or IPv6, its input color is detected by
> + * the innermost DSCP field indexing into the
> + * struct rte_mtr_params::dscp_table.
> + * Otherwise, the default_input_color is applied.
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::vlan_table
> + * @see struct rte_mtr_params::dscp_table
> + */
> + RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP =
> RTE_BIT64(6), };
> +
> /**
> * Parameters for each traffic metering & policing object
> *
> @@ -233,7 +307,15 @@ struct rte_mtr_params {
> */
> int use_prev_mtr_color;
>
> - /** Meter input color. When non-NULL: it points to a pre-allocated
> and
> + /** Meter input color based on IP DSCP field.
> + *
> + * Valid when input_color_method set to any of the following
> + * RTE_MTR_INPUT_COLOR_METHOD_DSCP,
> + * RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP,
> + * RTE_MTR_INPUT_COLOR_METHOD_INNER_DSCP,
> + * RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP
> + *
> + * When non-NULL: it points to a pre-allocated and
> * pre-populated table with exactly 64 elements providing the input
> * color for each value of the IPv4/IPv6 Differentiated Services Code
> * Point (DSCP) input packet field. When NULL: it is equivalent to @@
> -244,9 +326,39 @@ struct rte_mtr_params {
> * *use_prev_mtr_color* is non-zero value or when *dscp_table*
> contains
> * at least one yellow or red color element, then the color aware
> mode
> * is configured.
> + * @see enum
> rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_DSCP
> + * @see enum
> rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_VLAN_DS
> CP
> + * @see enum
> rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_D
> SCP
> + * @see enum
> rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_VL
> AN_DSCP
> + * @see struct rte_mtr_params::input_color_method
> */
> enum rte_color *dscp_table;
> -
> + /** Meter input color based on VLAN DEI(1bit), PCP(3 bits) fields.
> + *
> + * Valid when input_color_method set to any of the following
> + * RTE_MTR_INPUT_COLOR_METHOD_VLAN,
> + * RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP,
> + * RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN,
> + * RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP
> + *
> + * When non-NULL: it points to a pre-allocated and pre-populated
> + * table with exactly 16 elements providing the input color for
> + * each value of the DEI(1bit), PCP(3 bits) input packet field.
> + * When NULL: it is equivalent to setting this parameter to an
> + * all-green populated table (i.e. table with
> + * all the 16 elements set to green color). The color blind mode
> + * is configured by setting *use_prev_mtr_color* to 0 and
> + * *vlan_table* to either NULL or to an all-green
> + * populated table. When *use_prev_mtr_color* is non-zero value
> + * or when *vlan_table* contains at least one yellow or
> + * red color element, then the color aware mode is configured.
> + * @see enum
> rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_VLAN
> + * @see enum
> rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_VLAN_DS
> CP
> + * @see enum
> rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_VL
> AN
> + * @see enum
> rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_INNER_VL
> AN_DSCP
> + * @see struct rte_mtr_params::input_color_method
> + */
> + enum rte_color *vlan_table;
> /** Non-zero to enable the meter, zero to disable the meter at the
> time
> * of MTR object creation. Ignored when the meter profile indicated
> by
> * *meter_profile_id* is set to NONE.
> @@ -261,6 +373,20 @@ struct rte_mtr_params {
>
> /** Meter policy ID. @see rte_mtr_meter_policy_add() */
> uint32_t meter_policy_id;
> +
> + /** Input color method to select.
> + * @see struct rte_mtr_params::dscp_table
> + * @see struct rte_mtr_params::vlan_table
> + */
> + enum rte_mtr_input_color_method input_color_method;
> +
> + /** Input color to be set for the input packet when none of the
> + * enabled input color methods is applicable to the input packet.
> + * Ignored when this method is set to the
> + * enum
> rte_mtr_input_color_method::RTE_MTR_INPUT_COLOR_METHOD_COLOR_B
> LIND
> + * method.
> + */
> + enum rte_color default_input_color;
> };
>
> /**
> @@ -417,6 +543,16 @@ struct rte_mtr_capabilities {
> * @see enum rte_mtr_stats_type
> */
> uint64_t stats_mask;
> +
> + /** Set of supported input color methods.
> + * @see enum rte_mtr_input_color_method
> + */
> + uint64_t methods_mask;
> +
> + /** When non-zero, it indicates that driver supports separate
> + * input color table for given ethdev port.
> + */
> + int separate_input_color_table_per_port;
> };
>
> /**
> @@ -832,6 +968,30 @@ rte_mtr_meter_dscp_table_update(uint16_t
> port_id,
> enum rte_color *dscp_table,
> struct rte_mtr_error *error);
>
> +/**
> + * MTR object VLAN table update
> + *
> + * @param[in] port_id
> + * The port identifier of the Ethernet device.
> + * @param[in] mtr_id
> + * MTR object ID. Needs to be valid.
> + * @param[in] vlan_table
> + * When non-NULL: it points to a pre-allocated and pre-populated table
> with
> + * exactly 16 elements providing the input color for each value of the
> + * each value of the DEI(1bit), PCP(3 bits) input packet field.
> + * When NULL: it is equivalent to setting this parameter to an "all-green"
> + * populated table (i.e. table with all the 16 elements set to green color).
> + * @param[out] error
> + * Error details. Filled in only on error, when not NULL.
> + * @return
> + * 0 on success, non-zero error code otherwise.
> + */
> +__rte_experimental
> +int
> +rte_mtr_meter_vlan_table_update(uint16_t port_id,
> + uint32_t mtr_id,
> + enum rte_color *vlan_table,
> + struct rte_mtr_error *error);
> /**
> * MTR object enabled statistics counters update
> *
> diff --git a/lib/ethdev/rte_mtr_driver.h b/lib/ethdev/rte_mtr_driver.h index
> ee8c6ef7ad..37ab79666b 100644
> --- a/lib/ethdev/rte_mtr_driver.h
> +++ b/lib/ethdev/rte_mtr_driver.h
> @@ -97,6 +97,12 @@ typedef int
> (*rte_mtr_meter_dscp_table_update_t)(struct rte_eth_dev *dev,
> enum rte_color *dscp_table,
> struct rte_mtr_error *error);
>
> +/** @internal MTR object meter VLAN table update. */ typedef int
> +(*rte_mtr_meter_vlan_table_update_t)(struct rte_eth_dev *dev,
> + uint32_t mtr_id,
> + enum rte_color *vlan_table,
> + struct rte_mtr_error *error);
> +
> /** @internal MTR object enabled stats update. */ typedef int
> (*rte_mtr_stats_update_t)(struct rte_eth_dev *dev,
> uint32_t mtr_id,
> @@ -139,6 +145,9 @@ struct rte_mtr_ops {
> /** MTR object meter DSCP table update */
> rte_mtr_meter_dscp_table_update_t meter_dscp_table_update;
>
> + /** MTR object meter VLAN table update */
> + rte_mtr_meter_vlan_table_update_t meter_vlan_table_update;
> +
> /** MTR object enabled stats update */
> rte_mtr_stats_update_t stats_update;
>
> diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map index
> 20391ab29e..77915c0ddc 100644
> --- a/lib/ethdev/version.map
> +++ b/lib/ethdev/version.map
> @@ -279,6 +279,9 @@ EXPERIMENTAL {
> rte_flow_async_action_handle_create;
> rte_flow_async_action_handle_destroy;
> rte_flow_async_action_handle_update;
> +
> + # added in 22.07
> + rte_mtr_meter_vlan_table_update;
> };
>
> INTERNAL {
> --
> 2.25.1
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v3 1/1] ethdev: mtr: support input color selection
2022-03-01 8:58 ` [PATCH v3 1/1] " skori
2022-03-01 10:49 ` [EXT] " Sunil Kumar Kori
@ 2022-03-01 17:48 ` Dumitrescu, Cristian
2022-04-05 21:14 ` Dumitrescu, Cristian
2022-04-07 10:51 ` Jerin Jacob
2022-04-21 18:02 ` [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based " jerinj
2 siblings, 2 replies; 30+ messages in thread
From: Dumitrescu, Cristian @ 2022-03-01 17:48 UTC (permalink / raw)
To: skori, Thomas Monjalon, Yigit, Ferruh, Andrew Rybchenko, Ray Kinsella
Cc: dev, Jerin Jacob
HI Jerin,
Thanks for your patch! I think we are making great progress, here are a few more comments:
<snip>
> +/**
> + * Input color method
> + */
> +enum rte_mtr_input_color_method {
We should clean up the names of these methods a bit: we should not mix header names (VLAN, IP) with header field names (DSCP, PCP), in the sense that to me METHOD_VLAN_DSCP should be replaced with either:
* METHOD_OUTER_VLAN_IP :shorter name, as only the headers are mentioned (my preference, but I am OK with both)
* METHOD_OUTER_VLAN_PCP_IP_DSCP: longer name, as both the headers and the header fields are mentioned
Please put a blank line in between these methods to better readability.
I see some issues in the list of methods below, I am trying to do my best to catch them all:
> + /**
> + * The input color is always green.
> + * The default_input_color is ignored for this method.
> + * @see struct rte_mtr_params::default_input_color
> + */
> + RTE_MTR_INPUT_COLOR_METHOD_COLOR_BLIND = RTE_BIT64(0),
OK.
> + /**
> + * If the input packet has at least one VLAN label, its input color is
> + * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
> + * indexing into the struct rte_mtr_params::vlan_table.
> + * Otherwise, the default_input_color is applied.
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::vlan_table
> + */
> + RTE_MTR_INPUT_COLOR_METHOD_VLAN = RTE_BIT64(1),
OK.
Does your HW use PCP+DEI , or just PCP?
> + /**
> + * If the input packet is IPv4 or IPv6, its input color is detected by
> + * the outermost DSCP field indexing into the
> + * struct rte_mtr_params::dscp_table.
> + * Otherwise, the default_input_color is applied.
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::dscp_table
> + */
> + RTE_MTR_INPUT_COLOR_METHOD_DSCP = RTE_BIT64(2),
OK.
Please change name to METHOD_IP.
Description: Change the "outermost DSCP" to "the DSCP field of the outermost IP header".
I would move this up on the second position (to follow immediately after the color blind method).
> + /**
> + * If the input packet has at least one VLAN label, its input color is
> + * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
> + * indexing into the struct rte_mtr_params::vlan_table.
> + * If the input packet is IPv4 or IPv6, its input color is detected by
> + * the outermost DSCP field indexing into the
> + * struct rte_mtr_params::dscp_table.
> + * Otherwise, the default_input_color is applied.
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::vlan_table
> + * @see struct rte_mtr_params::dscp_table
> + */
> + RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP = RTE_BIT64(3),
OK.
Please change name to METHOD_VLAN_IP.
This should follow immediately after the METHOD_VLAN.
Description: please use "Otherwise" before "if the input packet is IP"; please replace "outermost DSCP" as above.
Is your HW using DEI + PCP or just PCP?
> + /**
> + * If the input packet has at least one VLAN label, its input color is
> + * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
> + * indexing into the struct rte_mtr_params::vlan_table.
> + * Otherwise, the default_input_color is applied.
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::vlan_table
> + */
> + RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN = RTE_BIT64(4),
OK.
Is your HW using DEI + PCP or just PCP?
> + /**
> + * If the input packet is IPv4 or IPv6, its input color is detected by
> + * the innermost DSCP field indexing into the
> + * struct rte_mtr_params::dscp_table.
> + * Otherwise, the default_input_color is applied.
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::dscp_table
> + */
> + RTE_MTR_INPUT_COLOR_METHOD_INNER_DSCP = RTE_BIT64(5),
This is very confusing to me, I don't get what this one is about: The "inner" word in the name suggests that inner VLAN is attempted first, then IP DSCP (if no VLAN is present), but the description only talks about IP.
> + /**
> + * If the input packet has at least one VLAN label, its input color is
> + * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
> + * indexing into the struct rte_mtr_params::vlan_table.
> + * If the input packet is IPv4 or IPv6, its input color is detected by
> + * the innermost DSCP field indexing into the
> + * struct rte_mtr_params::dscp_table.
> + * Otherwise, the default_input_color is applied.
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::vlan_table
> + * @see struct rte_mtr_params::dscp_table
> + */
> + RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP =
> RTE_BIT64(6),
OK.
Description fixes: Use "otherwise" before "if IP"; replace innermost DSCP with "DSCP field of the outermost IP header".
<snip>
Regards,
Cristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v3 1/1] ethdev: mtr: support input color selection
2022-03-01 17:48 ` Dumitrescu, Cristian
@ 2022-04-05 21:14 ` Dumitrescu, Cristian
2022-04-07 10:51 ` Jerin Jacob
1 sibling, 0 replies; 30+ messages in thread
From: Dumitrescu, Cristian @ 2022-04-05 21:14 UTC (permalink / raw)
To: Dumitrescu, Cristian, skori, Thomas Monjalon, Yigit, Ferruh,
Andrew Rybchenko, Ray Kinsella
Cc: dev, Jerin Jacob
Hi Jerin and folks, any update on this one? Thanks, Cristian
> -----Original Message-----
> From: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Sent: Tuesday, March 1, 2022 5:48 PM
> To: skori@marvell.com; Thomas Monjalon <thomas@monjalon.net>; Yigit,
> Ferruh <ferruh.yigit@intel.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; Ray Kinsella <mdr@ashroe.eu>
> Cc: dev@dpdk.org; Jerin Jacob <jerinj@marvell.com>
> Subject: RE: [PATCH v3 1/1] ethdev: mtr: support input color selection
>
> HI Jerin,
>
> Thanks for your patch! I think we are making great progress, here are a few
> more comments:
>
> <snip>
>
> > +/**
> > + * Input color method
> > + */
> > +enum rte_mtr_input_color_method {
>
> We should clean up the names of these methods a bit: we should not mix
> header names (VLAN, IP) with header field names (DSCP, PCP), in the sense
> that to me METHOD_VLAN_DSCP should be replaced with either:
> * METHOD_OUTER_VLAN_IP :shorter name, as only the headers are
> mentioned (my preference, but I am OK with both)
> * METHOD_OUTER_VLAN_PCP_IP_DSCP: longer name, as both the headers
> and the header fields are mentioned
>
> Please put a blank line in between these methods to better readability.
>
> I see some issues in the list of methods below, I am trying to do my best to
> catch them all:
>
> > + /**
> > + * The input color is always green.
> > + * The default_input_color is ignored for this method.
> > + * @see struct rte_mtr_params::default_input_color
> > + */
> > + RTE_MTR_INPUT_COLOR_METHOD_COLOR_BLIND = RTE_BIT64(0),
>
> OK.
>
> > + /**
> > + * If the input packet has at least one VLAN label, its input color is
> > + * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
> > + * indexing into the struct rte_mtr_params::vlan_table.
> > + * Otherwise, the default_input_color is applied.
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::vlan_table
> > + */
> > + RTE_MTR_INPUT_COLOR_METHOD_VLAN = RTE_BIT64(1),
>
> OK.
> Does your HW use PCP+DEI , or just PCP?
>
> > + /**
> > + * If the input packet is IPv4 or IPv6, its input color is detected by
> > + * the outermost DSCP field indexing into the
> > + * struct rte_mtr_params::dscp_table.
> > + * Otherwise, the default_input_color is applied.
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::dscp_table
> > + */
> > + RTE_MTR_INPUT_COLOR_METHOD_DSCP = RTE_BIT64(2),
>
> OK.
> Please change name to METHOD_IP.
> Description: Change the "outermost DSCP" to "the DSCP field of the outermost
> IP header".
> I would move this up on the second position (to follow immediately after the
> color blind method).
>
> > + /**
> > + * If the input packet has at least one VLAN label, its input color is
> > + * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
> > + * indexing into the struct rte_mtr_params::vlan_table.
> > + * If the input packet is IPv4 or IPv6, its input color is detected by
> > + * the outermost DSCP field indexing into the
> > + * struct rte_mtr_params::dscp_table.
> > + * Otherwise, the default_input_color is applied.
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::vlan_table
> > + * @see struct rte_mtr_params::dscp_table
> > + */
> > + RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP = RTE_BIT64(3),
>
> OK.
> Please change name to METHOD_VLAN_IP.
> This should follow immediately after the METHOD_VLAN.
> Description: please use "Otherwise" before "if the input packet is IP"; please
> replace "outermost DSCP" as above.
> Is your HW using DEI + PCP or just PCP?
>
> > + /**
> > + * If the input packet has at least one VLAN label, its input color is
> > + * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
> > + * indexing into the struct rte_mtr_params::vlan_table.
> > + * Otherwise, the default_input_color is applied.
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::vlan_table
> > + */
> > + RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN = RTE_BIT64(4),
>
> OK.
> Is your HW using DEI + PCP or just PCP?
>
> > + /**
> > + * If the input packet is IPv4 or IPv6, its input color is detected by
> > + * the innermost DSCP field indexing into the
> > + * struct rte_mtr_params::dscp_table.
> > + * Otherwise, the default_input_color is applied.
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::dscp_table
> > + */
> > + RTE_MTR_INPUT_COLOR_METHOD_INNER_DSCP = RTE_BIT64(5),
>
> This is very confusing to me, I don't get what this one is about: The "inner" word
> in the name suggests that inner VLAN is attempted first, then IP DSCP (if no
> VLAN is present), but the description only talks about IP.
>
> > + /**
> > + * If the input packet has at least one VLAN label, its input color is
> > + * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
> > + * indexing into the struct rte_mtr_params::vlan_table.
> > + * If the input packet is IPv4 or IPv6, its input color is detected by
> > + * the innermost DSCP field indexing into the
> > + * struct rte_mtr_params::dscp_table.
> > + * Otherwise, the default_input_color is applied.
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::vlan_table
> > + * @see struct rte_mtr_params::dscp_table
> > + */
> > + RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP =
> > RTE_BIT64(6),
>
> OK.
> Description fixes: Use "otherwise" before "if IP"; replace innermost DSCP with
> "DSCP field of the outermost IP header".
>
> <snip>
>
> Regards,
> Cristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v3 1/1] ethdev: mtr: support input color selection
2022-03-01 17:48 ` Dumitrescu, Cristian
2022-04-05 21:14 ` Dumitrescu, Cristian
@ 2022-04-07 10:51 ` Jerin Jacob
2022-04-07 13:25 ` Dumitrescu, Cristian
1 sibling, 1 reply; 30+ messages in thread
From: Jerin Jacob @ 2022-04-07 10:51 UTC (permalink / raw)
To: Dumitrescu, Cristian
Cc: skori, Thomas Monjalon, Yigit, Ferruh, Andrew Rybchenko,
Ray Kinsella, dev, Jerin Jacob
0 0 0 0
0 0 0 0
On Tue, Mar 1, 2022 at 11:18 PM Dumitrescu, Cristian
<cristian.dumitrescu@intel.com> wrote:
>
> HI Jerin,
Hi Cristian,
>
> Thanks for your patch! I think we are making great progress, here are a few more comments:
>
> <snip>
>
> > +/**
> > + * Input color method
> > + */
> > +enum rte_mtr_input_color_method {
>
> We should clean up the names of these methods a bit: we should not mix header names (VLAN, IP) with header field names (DSCP, PCP), in the sense that to me METHOD_VLAN_DSCP should be replaced with either:
> * METHOD_OUTER_VLAN_IP :shorter name, as only the headers are mentioned (my preference, but I am OK with both)
OK, We will keep VLAN and IP. By default OUTER is implicit in other
DPDK API spec,i.e if not mentioned, it is outer. Hence I removed the
outer. I can add outer explicit if you think in that way. See last
comment.
> * METHOD_OUTER_VLAN_PCP_IP_DSCP: longer name, as both the headers and the header fields are mentioned
>
> Please put a blank line in between these methods to better readability.
>
> I see some issues in the list of methods below, I am trying to do my best to catch them all:
Thanks. Sorry for the delay in reply.
>
> > + /**
> > + * The input color is always green.
> > + * The default_input_color is ignored for this method.
> > + * @see struct rte_mtr_params::default_input_color
> > + */
> > + RTE_MTR_INPUT_COLOR_METHOD_COLOR_BLIND = RTE_BIT64(0),
>
> OK.
>
> > + /**
> > + * If the input packet has at least one VLAN label, its input color is
> > + * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
> > + * indexing into the struct rte_mtr_params::vlan_table.
> > + * Otherwise, the default_input_color is applied.
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::vlan_table
> > + */
> > + RTE_MTR_INPUT_COLOR_METHOD_VLAN = RTE_BIT64(1),
>
> OK.
> Does your HW use PCP+DEI , or just PCP?
PCP + DEI
>
> > + /**
> > + * If the input packet is IPv4 or IPv6, its input color is detected by
> > + * the outermost DSCP field indexing into the
> > + * struct rte_mtr_params::dscp_table.
> > + * Otherwise, the default_input_color is applied.
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::dscp_table
> > + */
> > + RTE_MTR_INPUT_COLOR_METHOD_DSCP = RTE_BIT64(2),
>
> OK.
> Please change name to METHOD_IP.
> Description: Change the "outermost DSCP" to "the DSCP field of the outermost IP header".
OK
> I would move this up on the second position (to follow immediately after the color blind method).
Please check the summary below.
>
> > + /**
> > + * If the input packet has at least one VLAN label, its input color is
> > + * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
> > + * indexing into the struct rte_mtr_params::vlan_table.
> > + * If the input packet is IPv4 or IPv6, its input color is detected by
> > + * the outermost DSCP field indexing into the
> > + * struct rte_mtr_params::dscp_table.
> > + * Otherwise, the default_input_color is applied.
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::vlan_table
> > + * @see struct rte_mtr_params::dscp_table
> > + */
> > + RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP = RTE_BIT64(3),
>
> OK.
> Please change name to METHOD_VLAN_IP.
OK
> This should follow immediately after the METHOD_VLAN.
OK
> Description: please use "Otherwise" before "if the input packet is IP"; please replace "outermost DSCP" as above.
OK
> Is your HW using DEI + PCP or just PCP?
OK
>
> > + /**
> > + * If the input packet has at least one VLAN label, its input color is
> > + * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
> > + * indexing into the struct rte_mtr_params::vlan_table.
> > + * Otherwise, the default_input_color is applied.
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::vlan_table
> > + */
> > + RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN = RTE_BIT64(4),
>
> OK.
> Is your HW using DEI + PCP or just PCP?
DEI + PCP
>
> > + /**
> > + * If the input packet is IPv4 or IPv6, its input color is detected by
> > + * the innermost DSCP field indexing into the
> > + * struct rte_mtr_params::dscp_table.
> > + * Otherwise, the default_input_color is applied.
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::dscp_table
> > + */
> > + RTE_MTR_INPUT_COLOR_METHOD_INNER_DSCP = RTE_BIT64(5),
>
> This is very confusing to me, I don't get what this one is about: The "inner" word in the name suggests that inner VLAN is attempted first, then IP DSCP (if no VLAN is present), but the description only talks about IP.
This case attempts only inner IP DSCP. VLAN does not matter.
>
> > + /**
> > + * If the input packet has at least one VLAN label, its input color is
> > + * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
> > + * indexing into the struct rte_mtr_params::vlan_table.
> > + * If the input packet is IPv4 or IPv6, its input color is detected by
> > + * the innermost DSCP field indexing into the
> > + * struct rte_mtr_params::dscp_table.
> > + * Otherwise, the default_input_color is applied.
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::vlan_table
> > + * @see struct rte_mtr_params::dscp_table
> > + */
> > + RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP =
> > RTE_BIT64(6),
>
> OK.
> Description fixes: Use "otherwise" before "if IP"; replace innermost DSCP with "DSCP field of the outermost IP header".
OK.
To summarize we have 4 attributes, Please find below the truth table
1) Outer VLAN
2) Outer IP
3) Inner VLAN
4) Inner IP
Inner IP -Inner VLAN- Outer IP-Outer VLAN
0 0 0 0
- Not valid case
0 0 0 1
- RTE_MTR_INPUT_COLOR_METHOD_OUTER_VLAN
0 0 1 0
- RTE_MTR_INPUT_COLOR_METHOD_OUTER_IP
0 0 1 1
- RTE_MTR_INPUT_COLOR_METHOD_OUTER_VLAN_OUTER_IP - If found outer VLAN
then vlan else outer IP
0 1 0 0
- RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN
0 1 0 1
- RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_OUTER_VLAN - If found inner
VLAN else outer VLAN
0 1 1 0 -
RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_OUTER_IP
0 1 1 1 -
RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_OUTER_IP_OUTER_VLAN - If found
inner vlan then inner vlan else outer IP else outer VLAN
1 0 0 0 -
RTE_MTR_INPUT_COLOR_METHOD_INNER_IP
1 0 0 1 -
RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_OUTER_VLAN
1 0 1 0 -
RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_OUTER_IP
1 0 1 1 -
RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_OUTER_IP_OUTER_VLAN
1 1 0 0 -
RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_INNER_VLAN
1 1 0 1 -
RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_INNER_VLAN_OUTER_VLAN
1 1 1 0 -
RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_INNER_VLAN_OUTER_IP
1 1 1 1 -
RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_INNER_VLAN_OUTER_IP_OUTER_VLAN
Is this above enumeration fine, If not, Please suggest.
In Interms of name,
a) We could omit explicit OUTER to reduce the length as suggestion.
b) or change IIP, OIP, IVLAN, OVLAN kind of scheme to reduce the name.
Let me know the names and enumeration you prefer, I will change
accordingly in the next version?
>
> <snip>
>
> Regards,
> Cristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v3 1/1] ethdev: mtr: support input color selection
2022-04-07 10:51 ` Jerin Jacob
@ 2022-04-07 13:25 ` Dumitrescu, Cristian
2022-04-07 14:39 ` Jerin Jacob
0 siblings, 1 reply; 30+ messages in thread
From: Dumitrescu, Cristian @ 2022-04-07 13:25 UTC (permalink / raw)
To: Jerin Jacob
Cc: skori, Thomas Monjalon, Yigit, Ferruh, Andrew Rybchenko,
Ray Kinsella, dev, Jerin Jacob
>
> To summarize we have 4 attributes, Please find below the truth table
> 1) Outer VLAN
> 2) Outer IP
> 3) Inner VLAN
> 4) Inner IP
>
>
> Inner IP -Inner VLAN- Outer IP-Outer VLAN
> 0 0 0 0
> - Not valid case
> 0 0 0 1
> - RTE_MTR_INPUT_COLOR_METHOD_OUTER_VLAN
> 0 0 1 0
> - RTE_MTR_INPUT_COLOR_METHOD_OUTER_IP
> 0 0 1 1
> - RTE_MTR_INPUT_COLOR_METHOD_OUTER_VLAN_OUTER_IP - If found outer
> VLAN
> then vlan else outer IP
> 0 1 0 0
> - RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN
> 0 1 0 1
> - RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_OUTER_VLAN - If found
> inner
> VLAN else outer VLAN
> 0 1 1 0 -
> RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_OUTER_IP
> 0 1 1 1 -
> RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_OUTER_IP_OUTER_VLAN -
> If found
> inner vlan then inner vlan else outer IP else outer VLAN
> 1 0 0 0 -
> RTE_MTR_INPUT_COLOR_METHOD_INNER_IP
> 1 0 0 1 -
> RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_OUTER_VLAN
> 1 0 1 0 -
> RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_OUTER_IP
> 1 0 1 1 -
> RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_OUTER_IP_OUTER_VLAN
> 1 1 0 0 -
> RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_INNER_VLAN
> 1 1 0 1 -
> RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_INNER_VLAN_OUTER_VLAN
> 1 1 1 0 -
> RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_INNER_VLAN_OUTER_IP
> 1 1 1 1 -
>
> RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_INNER_VLAN_OUTER_IP_OUTE
> R_VLAN
>
> Is this above enumeration fine, If not, Please suggest.
>
> In Interms of name,
> a) We could omit explicit OUTER to reduce the length as suggestion.
> b) or change IIP, OIP, IVLAN, OVLAN kind of scheme to reduce the name.
>
> Let me know the names and enumeration you prefer, I will change
> accordingly in the next version?
>
Hi Jerin,
The above table looks confusing to me, I suggest we have a meeting next week to go over it and then report back to the list?
Regards,
Cristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v3 1/1] ethdev: mtr: support input color selection
2022-04-07 13:25 ` Dumitrescu, Cristian
@ 2022-04-07 14:39 ` Jerin Jacob
2022-04-11 14:45 ` Dumitrescu, Cristian
0 siblings, 1 reply; 30+ messages in thread
From: Jerin Jacob @ 2022-04-07 14:39 UTC (permalink / raw)
To: Dumitrescu, Cristian
Cc: skori, Thomas Monjalon, Yigit, Ferruh, Andrew Rybchenko,
Ray Kinsella, dev, Jerin Jacob
On Thu, Apr 7, 2022 at 6:55 PM Dumitrescu, Cristian
<cristian.dumitrescu@intel.com> wrote:
>
> >
> > To summarize we have 4 attributes, Please find below the truth table
> > 1) Outer VLAN
> > 2) Outer IP
> > 3) Inner VLAN
> > 4) Inner IP
> >
> >
> > Inner IP -Inner VLAN- Outer IP-Outer VLAN
> > 0 0 0 0
> > - Not valid case
> > 0 0 0 1
> > - RTE_MTR_INPUT_COLOR_METHOD_OUTER_VLAN
> > 0 0 1 0
> > - RTE_MTR_INPUT_COLOR_METHOD_OUTER_IP
> > 0 0 1 1
> > - RTE_MTR_INPUT_COLOR_METHOD_OUTER_VLAN_OUTER_IP - If found outer
> > VLAN
> > then vlan else outer IP
> > 0 1 0 0
> > - RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN
> > 0 1 0 1
> > - RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_OUTER_VLAN - If found
> > inner
> > VLAN else outer VLAN
> > 0 1 1 0 -
> > RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_OUTER_IP
> > 0 1 1 1 -
> > RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_OUTER_IP_OUTER_VLAN -
> > If found
> > inner vlan then inner vlan else outer IP else outer VLAN
> > 1 0 0 0 -
> > RTE_MTR_INPUT_COLOR_METHOD_INNER_IP
> > 1 0 0 1 -
> > RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_OUTER_VLAN
> > 1 0 1 0 -
> > RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_OUTER_IP
> > 1 0 1 1 -
> > RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_OUTER_IP_OUTER_VLAN
> > 1 1 0 0 -
> > RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_INNER_VLAN
> > 1 1 0 1 -
> > RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_INNER_VLAN_OUTER_VLAN
> > 1 1 1 0 -
> > RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_INNER_VLAN_OUTER_IP
> > 1 1 1 1 -
> >
> > RTE_MTR_INPUT_COLOR_METHOD_INNER_IP_INNER_VLAN_OUTER_IP_OUTE
> > R_VLAN
> >
> > Is this above enumeration fine, If not, Please suggest.
> >
> > In Interms of name,
> > a) We could omit explicit OUTER to reduce the length as suggestion.
> > b) or change IIP, OIP, IVLAN, OVLAN kind of scheme to reduce the name.
> >
> > Let me know the names and enumeration you prefer, I will change
> > accordingly in the next version?
> >
>
> Hi Jerin,
>
> The above table looks confusing to me, I suggest we have a meeting next week to go over it and then report back to the list?
Scheduled a meeting at 11th April - 6:30 IST
Agenda:
To discuss https://patches.dpdk.org/project/dpdk/patch/20220301085824.1041009-1-skori@marvell.com/
patch
Let me know, If time needs to change to include any interested participants.
Hi there,
Jerin Jacob is inviting you to a scheduled Zoom meeting.
Topic: Jerin Jacob Kollanukkaran's Personal Meeting Room
Join Zoom Meeting:
https://marvell.zoom.us/j/9901077677?pwd=T2lTTGMwYlc1YTQzMnR4eGRWQXR6QT09
Password: 339888
Or Telephone：
Dial(for higher quality, dial a number based on your current location)：
US: +1 301 715 8592 or +1 312 626 6799 or +1 346 248 7799
or +1 646 558 8656 or +1 669 900 6833 or +1 253 215 8782 or 888 788
0099 (Toll Free) or 833 548 0276 (Toll Free) or 833 548 0282 (Toll
Free) or 877 853 5247 (Toll Free)
Meeting ID: 990 107 7677
Password: 358309
International numbers available: https://marvell.zoom.us/u/adpcCpMHYt
Or a Video Conference Room:
From Touchpad: Tap Join Zoom button. When prompted, enter 990 107 7677
Password: 358309
For China locations, from Touchpad: Dial* then 990 107 7677
Password: 358309
>
> Regards,
> Cristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v3 1/1] ethdev: mtr: support input color selection
2022-04-07 14:39 ` Jerin Jacob
@ 2022-04-11 14:45 ` Dumitrescu, Cristian
2022-04-12 6:48 ` Ori Kam
0 siblings, 1 reply; 30+ messages in thread
From: Dumitrescu, Cristian @ 2022-04-11 14:45 UTC (permalink / raw)
To: dev, Thomas Monjalon, Andrew Rybchenko, Ray Kinsella
Cc: Jerin Jacob, Jerin Jacob, skori, Ori Kam
Hi folks,
Thanks to the community colleagues that participated to the call earlier today. Apologies for not CC-ing all the 9 attendants, as I don't have the email address for all of them.
We had a good meeting, I think we agreed on a good solution that will also simplify the API proposal.
Recap on the problem statement:
1. How do we decide on the input color for the current packet in a deterministic (implementation independent) way?
2. Multiple choices possible for a given packet: The same packet might contain multiple headers that can provide the input color. Examples: VLAN (the PCP and DEI fields), IP (DSCP field), others. Some headers of same type may show up in the same packet (e.g. outer/inner header).
3. Some of the possible choices might not be available for a given packet: Different packets may contain different headers.
Proposed solution:
1. Configure which protocols to enable. Example: we might want to consider Outer VLAN and Outer IP, but disable Inner VLAN and inner IP.
2. Configure on the priority of each of the enabled protocols (0 = highest priority). Example: If the current packet has an Outer VLAN header, but not an Outer IP header, then we get the input color from the Outer VLAN header; same, if there is an Outer IP header, but no Outer VLAN header, we get the priority from the Outer IP header. But what if the packet has both an Outer VLAN and an Outer IP header? In this case we need to consider the priority and pick the input color from the highest priority header.
3. Configure the default input color. What happens if the packet does not have an Outer VLAN header, nor an Outer IP header? Then the default input color is picked.
API guideline:
enum rte_mtr_color_in_protocol {
RTE_MTR_COLOR_IN_OUTER_VLAN,
RTE_MTR_COLOR_IN_INNER_VLAN,
RTE_MTR_COLOR_IN_OUTER_IP,
RTE_MTR_COLOR_IN_INNER_IP,
//more to add as needed. Per Ori's comment, we can add a reunion of the two protocols as well when needed, e.g. RTE_MTR_COLOR_IN_OUTER_VLAN_OUTER_IP that has a (4+6)-bit index (PCI, DEI, DSCP).
}
int
rte_mtr_color_in_protocol_priority_set(enum rte_mtr_color_in_protocol proto, uint32_t priority); //0 is highest priority
Regards,
Cristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v3 1/1] ethdev: mtr: support input color selection
2022-04-11 14:45 ` Dumitrescu, Cristian
@ 2022-04-12 6:48 ` Ori Kam
0 siblings, 0 replies; 30+ messages in thread
From: Ori Kam @ 2022-04-12 6:48 UTC (permalink / raw)
To: Dumitrescu, Cristian, dev, NBU-Contact-Thomas Monjalon (EXTERNAL),
Andrew Rybchenko, Ray Kinsella
Cc: Jerin Jacob, Jerin Jacob, skori, Vipin.Varghese, Alexander Kozyrev
Adding some missing guys, that I know about.
Ori
> -----Original Message-----
> From: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Sent: Monday, April 11, 2022 5:46 PM
> To: dev@dpdk.org; NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Andrew
> Rybchenko <andrew.rybchenko@oktetlabs.ru>; Ray Kinsella <mdr@ashroe.eu>
> Cc: Jerin Jacob <jerinjacobk@gmail.com>; Jerin Jacob <jerinj@marvell.com>; skori@marvell.com; Ori
> Kam <orika@nvidia.com>
> Subject: RE: [PATCH v3 1/1] ethdev: mtr: support input color selection
>
> Hi folks,
>
> Thanks to the community colleagues that participated to the call earlier today. Apologies for not CC-ing
> all the 9 attendants, as I don't have the email address for all of them.
>
> We had a good meeting, I think we agreed on a good solution that will also simplify the API proposal.
>
> Recap on the problem statement:
> 1. How do we decide on the input color for the current packet in a deterministic (implementation
> independent) way?
> 2. Multiple choices possible for a given packet: The same packet might contain multiple headers that
> can provide the input color. Examples: VLAN (the PCP and DEI fields), IP (DSCP field), others. Some
> headers of same type may show up in the same packet (e.g. outer/inner header).
> 3. Some of the possible choices might not be available for a given packet: Different packets may
> contain different headers.
>
> Proposed solution:
> 1. Configure which protocols to enable. Example: we might want to consider Outer VLAN and Outer IP,
> but disable Inner VLAN and inner IP.
> 2. Configure on the priority of each of the enabled protocols (0 = highest priority). Example: If the
> current packet has an Outer VLAN header, but not an Outer IP header, then we get the input color
> from the Outer VLAN header; same, if there is an Outer IP header, but no Outer VLAN header, we get
> the priority from the Outer IP header. But what if the packet has both an Outer VLAN and an Outer IP
> header? In this case we need to consider the priority and pick the input color from the highest priority
> header.
> 3. Configure the default input color. What happens if the packet does not have an Outer VLAN header,
> nor an Outer IP header? Then the default input color is picked.
>
> API guideline:
> enum rte_mtr_color_in_protocol {
> RTE_MTR_COLOR_IN_OUTER_VLAN,
> RTE_MTR_COLOR_IN_INNER_VLAN,
> RTE_MTR_COLOR_IN_OUTER_IP,
> RTE_MTR_COLOR_IN_INNER_IP,
> //more to add as needed. Per Ori's comment, we can add a reunion of the two protocols as
> well when needed, e.g. RTE_MTR_COLOR_IN_OUTER_VLAN_OUTER_IP that has a (4+6)-bit index
> (PCI, DEI, DSCP).
> }
>
> int
> rte_mtr_color_in_protocol_priority_set(enum rte_mtr_color_in_protocol proto, uint32_t priority);
> //0 is highest priority
>
> Regards,
> Cristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based input color selection
2022-03-01 8:58 ` [PATCH v3 1/1] " skori
2022-03-01 10:49 ` [EXT] " Sunil Kumar Kori
2022-03-01 17:48 ` Dumitrescu, Cristian
@ 2022-04-21 18:02 ` jerinj
2022-04-26 10:19 ` Ray Kinsella
` (2 more replies)
2 siblings, 3 replies; 30+ messages in thread
From: jerinj @ 2022-04-21 18:02 UTC (permalink / raw)
To: dev, Cristian Dumitrescu, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko, Ray Kinsella
Cc: ajit.khaparde, aboyer, beilei.xing, bruce.richardson, chas3,
chenbo.xia, ciara.loftus, dsinghrawat, ed.czeck, evgenys, grive,
g.singh, zhouguoyang, haiyue.wang, hkalra, heinrich.kuhn,
hemant.agrawal, hyonkim, igorch, irusskikh, jgrajcia,
jasvinder.singh, jianwang, jiawenwu, jingjing.wu, johndale,
john.miller, linville, keith.wiles, kirankumark, oulijun, lironh,
longli, mw, spinler, matan, matt.peters, maxime.coquelin, mk,
humin29, pnalla, ndabilpuram, qiming.yang, qi.z.zhang, radhac,
rahul.lakkireddy, rmody, rosen.xu, sachin.saxena, skoteshwar,
shshaikh, shaibran, shepard.siegel, asomalap, somnath.kotur,
sthemmin, steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2, Jerin Jacob
From: Jerin Jacob <jerinj@marvell.com>
Currently, meter object supports only DSCP based on input color table,
The patch enhance that to support VLAN based input color table,
color table based on inner field for the tunnel use case, and
support for fallback color per meter if packet based on a different field.
All of the above features are exposed through capability and added
additional capability to specify the implementation supports
more than one input color table per ethdev port.
Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---
v4..v3:
- Aligned with community meeting call which is documented in
https://patches.dpdk.org/project/dpdk/patch/20220301085824.1041009-1-skori@marvell.com/
as last message. With following exception,
- Used RTE_MTR_COLOR_IN_*_DSCP instead of RTE_MTR_COLOR_IN_*_IP as
there is already dscp_table and rte_mtr_meter_dscp_table_update() API.
Changing above symbols break existing application for no good.
- Updated 22.07 release notes
- Remove testpmd changes from series to finalize the API spec first and
then we can send testpmd changes.
v3..v2:
- Fix input color flags as a bitmask
- Add definitions for newly added API
v2..v1:
- Fix seperate typo
v1..RFC:
Address the review comments by Cristian at
https://patches.dpdk.org/project/dpdk/patch/20210820082401.3778736-1-jerinj@marvell.com/
- Moved to v22.07 release
- Updated rte_mtr_input_color_method to support all VLAN, DSCP, Inner
cases
- Added input_color_method
- Removed union between vlan_table and dscp_table
- Kept VLAN instead of PCP as HW coloring based on DEI(1bit), PCP(3
bits)
.../traffic_metering_and_policing.rst | 33 ++++
doc/guides/rel_notes/release_22_07.rst | 10 +
lib/ethdev/rte_mtr.c | 23 +++
lib/ethdev/rte_mtr.h | 186 +++++++++++++++++-
lib/ethdev/rte_mtr_driver.h | 19 ++
lib/ethdev/version.map | 4 +
6 files changed, 265 insertions(+), 10 deletions(-)
diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst
index ceb5a96488..75deabbaf1 100644
--- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
+++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
@@ -21,6 +21,7 @@ The main features are:
* Policer actions (per meter output color): recolor, drop
* Statistics (per policer output color)
* Chaining multiple meter objects
+* Protocol based input color selection
Configuration steps
-------------------
@@ -105,3 +106,35 @@ traffic meter and policing library.
* Adding one (or multiple) actions of the type ``RTE_FLOW_ACTION_TYPE_METER``
to the list of meter actions (``struct rte_mtr_meter_policy_params::actions``)
specified per color as show in :numref:`figure_rte_mtr_chaining`.
+
+Protocol based input color selection
+------------------------------------
+
+The API supports selecting the input color based on the packet content.
+Following is the API usage model for the same.
+
+#. Probe the protocol based input color selection device capabilities using
+ following parameter using ``rte_mtr_capabilities_get()`` API.
+
+ * ``struct rte_mtr_capabilities::input_color_proto_mask;``
+ * ``struct rte_mtr_capabilities::separate_input_color_table_per_port``
+
+#. When creating the meter object using ``rte_mtr_create()``, configure
+ relevant input color selection parameters such as
+
+ * Input color protocols with ``struct rte_mtr_params::input_color_proto_mask``
+
+ * If ``struct rte_mtr_params::input_color_proto_mask`` has multiple bits set then
+ ``rte_mtr_color_in_protocol_priority_set()`` shall be used to set the priority,
+ in the order, in which protocol to be used to find the input color.
+
+ * Fill the tables ``struct rte_mtr_params::dscp_table``,
+ ``struct rte_mtr_params::vlan_table`` based on input color selected.
+
+ * Update the ``struct rte_mtr_params::default_input_color`` to determine
+ the default input color in case the input packet does not match
+ the input color method.
+
+ * If needed, update the input color table at runtime using
+ ``rte_mtr_meter_vlan_table_update()`` and ``rte_mtr_meter_dscp_table_update()``
+ APIs.
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index 42a5f2d990..746622f9b3 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -55,6 +55,13 @@ New Features
Also, make sure to start the actual text at the margin.
=======================================================
+* **Added protocol based input color for meter.**
+
+ Added new APIs ``rte_mtr_color_in_protocol_priority_set()``,
+ ``rte_mtr_meter_vlan_table_update()`` and updated ``struct rte_mtr_params``
+ and ``struct rte_mtr_capabilities`` to support protocol based
+ input color for meter.
+
Removed Items
-------------
@@ -102,6 +109,9 @@ ABI Changes
* No ABI change that would break compatibility with 21.11.
+* Experimental structures ``struct rte_mtr_params``
+ and ``struct rte_mtr_capabilities`` updated to support
+ protocol based input color for meter.
Known Issues
------------
diff --git a/lib/ethdev/rte_mtr.c b/lib/ethdev/rte_mtr.c
index e49fcf271c..a112fe65f5 100644
--- a/lib/ethdev/rte_mtr.c
+++ b/lib/ethdev/rte_mtr.c
@@ -207,6 +207,29 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
mtr_id, dscp_table, error);
}
+/** MTR object meter VLAN table update */
+int
+rte_mtr_meter_vlan_table_update(uint16_t port_id, uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ return RTE_MTR_FUNC(port_id, meter_vlan_table_update)(dev,
+ mtr_id, vlan_table, error);
+}
+
+/** Set the priority for input color protocol on MTR object */
+int
+rte_mtr_color_in_protocol_priority_set(uint16_t port_id, uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto,
+ uint32_t priority,
+ struct rte_mtr_error *error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ return RTE_MTR_FUNC(port_id, in_proto_prio_set)(dev,
+ mtr_id, proto, priority, error);
+}
+
/** MTR object enabled stats update */
int
rte_mtr_stats_update(uint16_t port_id,
diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h
index 40df0888c8..76ffbcf724 100644
--- a/lib/ethdev/rte_mtr.h
+++ b/lib/ethdev/rte_mtr.h
@@ -213,6 +213,52 @@ struct rte_mtr_meter_policy_params {
const struct rte_flow_action *actions[RTE_COLORS];
};
+/**
+ * Input color protocol method
+ */
+enum rte_mtr_color_in_protocol {
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * Otherwise, the *default_input_color* is applied.
+ *
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN = RTE_BIT64(0),
+ /**
+ * If the input packet has at least one VLAN label, its input color is
+ * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
+ * indexing into the struct rte_mtr_params::vlan_table.
+ * Otherwise, the *default_input_color* is applied.
+ *
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::vlan_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_INNER_VLAN = RTE_BIT64(1),
+ /**
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the outermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the *default_input_color* is applied.
+ *
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP = RTE_BIT64(2),
+ /**
+ * If the input packet is IPv4 or IPv6, its input color is detected by
+ * the innermost DSCP field indexing into the
+ * struct rte_mtr_params::dscp_table.
+ * Otherwise, the *default_input_color* is applied.
+ *
+ * @see struct rte_mtr_params::default_input_color
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_INNER_DSCP = RTE_BIT64(3),
+};
+
/**
* Parameters for each traffic metering & policing object
*
@@ -233,20 +279,58 @@ struct rte_mtr_params {
*/
int use_prev_mtr_color;
- /** Meter input color. When non-NULL: it points to a pre-allocated and
+ /** Meter input color based on IP DSCP protocol field.
+ *
+ * Valid when *input_color_proto_mask* set to any of the following
+ * RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP,
+ * RTE_MTR_COLOR_IN_PROTO_INNER_DSCP
+ *
+ * When non-NULL: it points to a pre-allocated and
* pre-populated table with exactly 64 elements providing the input
* color for each value of the IPv4/IPv6 Differentiated Services Code
- * Point (DSCP) input packet field. When NULL: it is equivalent to
- * setting this parameter to an all-green populated table (i.e. table
- * with all the 64 elements set to green color). The color blind mode
- * is configured by setting *use_prev_mtr_color* to 0 and *dscp_table*
- * to either NULL or to an all-green populated table. When
- * *use_prev_mtr_color* is non-zero value or when *dscp_table* contains
- * at least one yellow or red color element, then the color aware mode
- * is configured.
+ * Point (DSCP) input packet field.
+ *
+ * When NULL: it is equivalent to setting this parameter to an all-green
+ * populated table (i.e. table with all the 64 elements set to green
+ * color). The color blind mode is configured by setting
+ * *use_prev_mtr_color* to 0 and *dscp_table* to either NULL or to an
+ * all-green populated table.
+ *
+ * When *use_prev_mtr_color* is non-zero value or when *dscp_table*
+ * contains at least one yellow or red color element, then the color
+ * aware mode is configured.
+ *
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_DSCP
+ * @see struct rte_mtr_params::input_color_proto_mask
*/
enum rte_color *dscp_table;
-
+ /** Meter input color based on VLAN DEI(1bit), PCP(3 bits) protocol
+ * fields.
+ *
+ * Valid when *input_color_proto_mask* set to any of the following
+ * RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN,
+ * RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
+ *
+ * When non-NULL: it points to a pre-allocated and pre-populated
+ * table with exactly 16 elements providing the input color for
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ *
+ * When NULL: it is equivalent to setting this parameter to an
+ * all-green populated table (i.e. table with
+ * all the 16 elements set to green color). The color blind mode
+ * is configured by setting *use_prev_mtr_color* to 0 and
+ * *vlan_table* to either NULL or to an all-green populated table.
+ *
+ * When *use_prev_mtr_color* is non-zero value
+ * or when *vlan_table* contains at least one yellow or
+ * red color element, then the color aware mode is configured.
+ *
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
+ * @see struct rte_mtr_params::input_color_proto_mask
+ */
+ enum rte_color *vlan_table;
/** Non-zero to enable the meter, zero to disable the meter at the time
* of MTR object creation. Ignored when the meter profile indicated by
* *meter_profile_id* is set to NONE.
@@ -261,6 +345,25 @@ struct rte_mtr_params {
/** Meter policy ID. @see rte_mtr_meter_policy_add() */
uint32_t meter_policy_id;
+
+ /** Set of input color protocols to be enabled.
+ *
+ * Set value to zero to configure as color blind mode.
+ *
+ * When multiple bits set then rte_mtr_color_in_protocol_priority_set()
+ * shall be used to set the priority, in the order, in which protocol
+ * to be used to find the inpput color.
+ *
+ * @see enum rte_mtr_color_in_protocol
+ * @see rte_mtr_color_in_protocol_priority_set()
+ */
+ uint64_t input_color_proto_mask;
+
+ /** Input color to be set for the input packet when none of the
+ * enabled input color methods is applicable to the input packet.
+ * Ignored when this when *input_color_proto_mask* set to zero.
+ */
+ enum rte_color default_input_color;
};
/**
@@ -417,6 +520,16 @@ struct rte_mtr_capabilities {
* @see enum rte_mtr_stats_type
*/
uint64_t stats_mask;
+
+ /** Set of supported input color protocol.
+ * @see enum rte_mtr_color_in_protocol
+ */
+ uint64_t input_color_proto_mask;
+
+ /** When non-zero, it indicates that driver supports separate
+ * input color table for given ethdev port.
+ */
+ int separate_input_color_table_per_port;
};
/**
@@ -832,6 +945,59 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
enum rte_color *dscp_table,
struct rte_mtr_error *error);
+/**
+ * MTR object VLAN table update
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[in] vlan_table
+ * When non-NULL: it points to a pre-allocated and pre-populated table with
+ * exactly 16 elements providing the input color for each value of the
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ * When NULL: it is equivalent to setting this parameter to an "all-green"
+ * populated table (i.e. table with all the 16 elements set to green color).
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+__rte_experimental
+int
+rte_mtr_meter_vlan_table_update(uint16_t port_id, uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error);
+/**
+ * Set the priority for input color protocol
+ *
+ * When multiple bits set in struct rte_mtr_params::input_color_proto_mask
+ * then this API shall be used to set the priority, in the order, in
+ * which protocol to be used to find the input color.
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[in] proto
+ * Input color protocol to apply priority.
+ * MTR object's *input_color_proto_mask* should be configured
+ * with proto value.
+ * @param[in] priority
+ * Input color protocol priority. Value zero indicates
+ * the highest priority.
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ *
+ * @see rte_mtr_params::input_color_proto_mask
+ */
+__rte_experimental
+int
+rte_mtr_color_in_protocol_priority_set(uint16_t port_id, uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto, uint32_t priority,
+ struct rte_mtr_error *error);
/**
* MTR object enabled statistics counters update
*
diff --git a/lib/ethdev/rte_mtr_driver.h b/lib/ethdev/rte_mtr_driver.h
index ee8c6ef7ad..827952adc6 100644
--- a/lib/ethdev/rte_mtr_driver.h
+++ b/lib/ethdev/rte_mtr_driver.h
@@ -97,6 +97,19 @@ typedef int (*rte_mtr_meter_dscp_table_update_t)(struct rte_eth_dev *dev,
enum rte_color *dscp_table,
struct rte_mtr_error *error);
+/** @internal mtr object meter vlan table update. */
+typedef int (*rte_mtr_meter_vlan_table_update_t)(struct rte_eth_dev *dev,
+ uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error);
+
+/** @internal Set the priority for input color protocol on MTR object. */
+typedef int (*rte_mtr_meter_color_in_proto_prio_set_t)(struct rte_eth_dev *dev,
+ uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto,
+ uint32_t priority,
+ struct rte_mtr_error *error);
+
/** @internal MTR object enabled stats update. */
typedef int (*rte_mtr_stats_update_t)(struct rte_eth_dev *dev,
uint32_t mtr_id,
@@ -139,6 +152,12 @@ struct rte_mtr_ops {
/** MTR object meter DSCP table update */
rte_mtr_meter_dscp_table_update_t meter_dscp_table_update;
+ /** MTR object meter VLAN table update */
+ rte_mtr_meter_vlan_table_update_t meter_vlan_table_update;
+
+ /** Set the priority for input color protocol on MTR object. */
+ rte_mtr_meter_color_in_proto_prio_set_t in_proto_prio_set;
+
/** MTR object enabled stats update */
rte_mtr_stats_update_t stats_update;
diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
index 20391ab29e..cccbf6dee5 100644
--- a/lib/ethdev/version.map
+++ b/lib/ethdev/version.map
@@ -279,6 +279,10 @@ EXPERIMENTAL {
rte_flow_async_action_handle_create;
rte_flow_async_action_handle_destroy;
rte_flow_async_action_handle_update;
+
+ # added in 22.07
+ rte_mtr_meter_vlan_table_update;
+ rte_mtr_color_in_protocol_priority_set;
};
INTERNAL {
--
2.36.0
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based input color selection
2022-04-21 18:02 ` [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based " jerinj
@ 2022-04-26 10:19 ` Ray Kinsella
2022-05-01 12:52 ` Jerin Jacob
2022-04-26 12:08 ` Dumitrescu, Cristian
2022-05-01 14:46 ` [dpdk-dev] [PATCH v5] " jerinj
2 siblings, 1 reply; 30+ messages in thread
From: Ray Kinsella @ 2022-04-26 10:19 UTC (permalink / raw)
To: jerinj
Cc: dev, Cristian Dumitrescu, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko, ajit.khaparde, aboyer, beilei.xing,
bruce.richardson, chas3, chenbo.xia, ciara.loftus, dsinghrawat,
ed.czeck, evgenys, grive, g.singh, zhouguoyang, haiyue.wang,
hkalra, heinrich.kuhn, hemant.agrawal, hyonkim, igorch,
irusskikh, jgrajcia, jasvinder.singh, jianwang, jiawenwu,
jingjing.wu, johndale, john.miller, linville, keith.wiles,
kirankumark, oulijun, lironh, longli, mw, spinler, matan,
matt.peters, maxime.coquelin, mk, humin29, pnalla, ndabilpuram,
qiming.yang, qi.z.zhang, radhac, rahul.lakkireddy, rmody,
rosen.xu, sachin.saxena, skoteshwar, shshaikh, shaibran,
shepard.siegel, asomalap, somnath.kotur, sthemmin,
steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2
jerinj@marvell.com writes:
> From: Jerin Jacob <jerinj@marvell.com>
>
> Currently, meter object supports only DSCP based on input color table,
> The patch enhance that to support VLAN based input color table,
> color table based on inner field for the tunnel use case, and
> support for fallback color per meter if packet based on a different field.
>
> All of the above features are exposed through capability and added
> additional capability to specify the implementation supports
> more than one input color table per ethdev port.
>
> Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> ---
> v4..v3:
>
> - Aligned with community meeting call which is documented in
> https://patches.dpdk.org/project/dpdk/patch/20220301085824.1041009-1-skori@marvell.com/
> as last message. With following exception,
> - Used RTE_MTR_COLOR_IN_*_DSCP instead of RTE_MTR_COLOR_IN_*_IP as
> there is already dscp_table and rte_mtr_meter_dscp_table_update() API.
> Changing above symbols break existing application for no good.
> - Updated 22.07 release notes
> - Remove testpmd changes from series to finalize the API spec first and
> then we can send testpmd changes.
>
> v3..v2:
>
> - Fix input color flags as a bitmask
> - Add definitions for newly added API
>
> v2..v1:
> - Fix seperate typo
>
> v1..RFC:
>
> Address the review comments by Cristian at
> https://patches.dpdk.org/project/dpdk/patch/20210820082401.3778736-1-jerinj@marvell.com/
>
> - Moved to v22.07 release
> - Updated rte_mtr_input_color_method to support all VLAN, DSCP, Inner
> cases
> - Added input_color_method
> - Removed union between vlan_table and dscp_table
> - Kept VLAN instead of PCP as HW coloring based on DEI(1bit), PCP(3
> bits)
>
> .../traffic_metering_and_policing.rst | 33 ++++
> doc/guides/rel_notes/release_22_07.rst | 10 +
> lib/ethdev/rte_mtr.c | 23 +++
> lib/ethdev/rte_mtr.h | 186 +++++++++++++++++-
> lib/ethdev/rte_mtr_driver.h | 19 ++
> lib/ethdev/version.map | 4 +
> 6 files changed, 265 insertions(+), 10 deletions(-)
>
> diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst
> index ceb5a96488..75deabbaf1 100644
> --- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
> +++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
> @@ -21,6 +21,7 @@ The main features are:
> * Policer actions (per meter output color): recolor, drop
> * Statistics (per policer output color)
> * Chaining multiple meter objects
> +* Protocol based input color selection
>
> Configuration steps
> -------------------
> @@ -105,3 +106,35 @@ traffic meter and policing library.
> * Adding one (or multiple) actions of the type ``RTE_FLOW_ACTION_TYPE_METER``
> to the list of meter actions (``struct rte_mtr_meter_policy_params::actions``)
> specified per color as show in :numref:`figure_rte_mtr_chaining`.
> +
> +Protocol based input color selection
> +------------------------------------
> +
> +The API supports selecting the input color based on the packet content.
> +Following is the API usage model for the same.
> +
> +#. Probe the protocol based input color selection device capabilities using
> + following parameter using ``rte_mtr_capabilities_get()`` API.
> +
> + * ``struct rte_mtr_capabilities::input_color_proto_mask;``
> + * ``struct rte_mtr_capabilities::separate_input_color_table_per_port``
> +
> +#. When creating the meter object using ``rte_mtr_create()``, configure
> + relevant input color selection parameters such as
> +
> + * Input color protocols with ``struct rte_mtr_params::input_color_proto_mask``
> +
> + * If ``struct rte_mtr_params::input_color_proto_mask`` has multiple bits set then
> + ``rte_mtr_color_in_protocol_priority_set()`` shall be used to set the priority,
> + in the order, in which protocol to be used to find the input color.
> +
> + * Fill the tables ``struct rte_mtr_params::dscp_table``,
> + ``struct rte_mtr_params::vlan_table`` based on input color selected.
> +
> + * Update the ``struct rte_mtr_params::default_input_color`` to determine
> + the default input color in case the input packet does not match
> + the input color method.
> +
> + * If needed, update the input color table at runtime using
> + ``rte_mtr_meter_vlan_table_update()`` and ``rte_mtr_meter_dscp_table_update()``
> + APIs.
> diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
> index 42a5f2d990..746622f9b3 100644
> --- a/doc/guides/rel_notes/release_22_07.rst
> +++ b/doc/guides/rel_notes/release_22_07.rst
> @@ -55,6 +55,13 @@ New Features
> Also, make sure to start the actual text at the margin.
> =======================================================
>
> +* **Added protocol based input color for meter.**
> +
> + Added new APIs ``rte_mtr_color_in_protocol_priority_set()``,
> + ``rte_mtr_meter_vlan_table_update()`` and updated ``struct rte_mtr_params``
> + and ``struct rte_mtr_capabilities`` to support protocol based
> + input color for meter.
> +
>
> Removed Items
> -------------
> @@ -102,6 +109,9 @@ ABI Changes
>
> * No ABI change that would break compatibility with 21.11.
>
> +* Experimental structures ``struct rte_mtr_params``
> + and ``struct rte_mtr_capabilities`` updated to support
> + protocol based input color for meter.
>
> Known Issues
> ------------
> diff --git a/lib/ethdev/rte_mtr.c b/lib/ethdev/rte_mtr.c
> index e49fcf271c..a112fe65f5 100644
> --- a/lib/ethdev/rte_mtr.c
> +++ b/lib/ethdev/rte_mtr.c
> @@ -207,6 +207,29 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
> mtr_id, dscp_table, error);
> }
>
> +/** MTR object meter VLAN table update */
> +int
> +rte_mtr_meter_vlan_table_update(uint16_t port_id, uint32_t mtr_id,
> + enum rte_color *vlan_table,
> + struct rte_mtr_error *error)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + return RTE_MTR_FUNC(port_id, meter_vlan_table_update)(dev,
> + mtr_id, vlan_table, error);
> +}
> +
> +/** Set the priority for input color protocol on MTR object */
> +int
> +rte_mtr_color_in_protocol_priority_set(uint16_t port_id, uint32_t mtr_id,
> + enum rte_mtr_color_in_protocol proto,
> + uint32_t priority,
> + struct rte_mtr_error *error)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + return RTE_MTR_FUNC(port_id, in_proto_prio_set)(dev,
> + mtr_id, proto, priority, error);
> +}
> +
> /** MTR object enabled stats update */
> int
> rte_mtr_stats_update(uint16_t port_id,
> diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h
> index 40df0888c8..76ffbcf724 100644
> --- a/lib/ethdev/rte_mtr.h
> +++ b/lib/ethdev/rte_mtr.h
> @@ -213,6 +213,52 @@ struct rte_mtr_meter_policy_params {
> const struct rte_flow_action *actions[RTE_COLORS];
> };
>
> +/**
> + * Input color protocol method
> + */
> +enum rte_mtr_color_in_protocol {
> + /**
> + * If the input packet has at least one VLAN label, its input color is
> + * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
> + * indexing into the struct rte_mtr_params::vlan_table.
> + * Otherwise, the *default_input_color* is applied.
> + *
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::vlan_table
> + */
> + RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN = RTE_BIT64(0),
> + /**
> + * If the input packet has at least one VLAN label, its input color is
> + * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
> + * indexing into the struct rte_mtr_params::vlan_table.
> + * Otherwise, the *default_input_color* is applied.
> + *
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::vlan_table
> + */
> + RTE_MTR_COLOR_IN_PROTO_INNER_VLAN = RTE_BIT64(1),
> + /**
> + * If the input packet is IPv4 or IPv6, its input color is detected by
> + * the outermost DSCP field indexing into the
> + * struct rte_mtr_params::dscp_table.
> + * Otherwise, the *default_input_color* is applied.
> + *
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::dscp_table
> + */
> + RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP = RTE_BIT64(2),
> + /**
> + * If the input packet is IPv4 or IPv6, its input color is detected by
> + * the innermost DSCP field indexing into the
> + * struct rte_mtr_params::dscp_table.
> + * Otherwise, the *default_input_color* is applied.
> + *
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::dscp_table
> + */
> + RTE_MTR_COLOR_IN_PROTO_INNER_DSCP = RTE_BIT64(3),
> +};
> +
> /**
> * Parameters for each traffic metering & policing object
> *
> @@ -233,20 +279,58 @@ struct rte_mtr_params {
> */
> int use_prev_mtr_color;
>
> - /** Meter input color. When non-NULL: it points to a pre-allocated and
> + /** Meter input color based on IP DSCP protocol field.
> + *
> + * Valid when *input_color_proto_mask* set to any of the following
> + * RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP,
> + * RTE_MTR_COLOR_IN_PROTO_INNER_DSCP
> + *
> + * When non-NULL: it points to a pre-allocated and
> * pre-populated table with exactly 64 elements providing the input
> * color for each value of the IPv4/IPv6 Differentiated Services Code
> - * Point (DSCP) input packet field. When NULL: it is equivalent to
> - * setting this parameter to an all-green populated table (i.e. table
> - * with all the 64 elements set to green color). The color blind mode
> - * is configured by setting *use_prev_mtr_color* to 0 and *dscp_table*
> - * to either NULL or to an all-green populated table. When
> - * *use_prev_mtr_color* is non-zero value or when *dscp_table* contains
> - * at least one yellow or red color element, then the color aware mode
> - * is configured.
> + * Point (DSCP) input packet field.
> + *
> + * When NULL: it is equivalent to setting this parameter to an all-green
> + * populated table (i.e. table with all the 64 elements set to green
> + * color). The color blind mode is configured by setting
> + * *use_prev_mtr_color* to 0 and *dscp_table* to either NULL or to an
> + * all-green populated table.
> + *
> + * When *use_prev_mtr_color* is non-zero value or when *dscp_table*
> + * contains at least one yellow or red color element, then the color
> + * aware mode is configured.
> + *
> + * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP
> + * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_DSCP
> + * @see struct rte_mtr_params::input_color_proto_mask
> */
> enum rte_color *dscp_table;
> -
> + /** Meter input color based on VLAN DEI(1bit), PCP(3 bits) protocol
> + * fields.
> + *
> + * Valid when *input_color_proto_mask* set to any of the following
> + * RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN,
> + * RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
> + *
> + * When non-NULL: it points to a pre-allocated and pre-populated
> + * table with exactly 16 elements providing the input color for
> + * each value of the DEI(1bit), PCP(3 bits) input packet field.
> + *
> + * When NULL: it is equivalent to setting this parameter to an
> + * all-green populated table (i.e. table with
> + * all the 16 elements set to green color). The color blind mode
> + * is configured by setting *use_prev_mtr_color* to 0 and
> + * *vlan_table* to either NULL or to an all-green populated table.
> + *
> + * When *use_prev_mtr_color* is non-zero value
> + * or when *vlan_table* contains at least one yellow or
> + * red color element, then the color aware mode is configured.
> + *
> + * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN
> + * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
> + * @see struct rte_mtr_params::input_color_proto_mask
> + */
> + enum rte_color *vlan_table;
> /** Non-zero to enable the meter, zero to disable the meter at the time
> * of MTR object creation. Ignored when the meter profile indicated by
> * *meter_profile_id* is set to NONE.
> @@ -261,6 +345,25 @@ struct rte_mtr_params {
>
> /** Meter policy ID. @see rte_mtr_meter_policy_add() */
> uint32_t meter_policy_id;
> +
> + /** Set of input color protocols to be enabled.
> + *
> + * Set value to zero to configure as color blind mode.
> + *
> + * When multiple bits set then rte_mtr_color_in_protocol_priority_set()
> + * shall be used to set the priority, in the order, in which protocol
> + * to be used to find the inpput color.
> + *
> + * @see enum rte_mtr_color_in_protocol
> + * @see rte_mtr_color_in_protocol_priority_set()
> + */
> + uint64_t input_color_proto_mask;
> +
> + /** Input color to be set for the input packet when none of the
> + * enabled input color methods is applicable to the input packet.
> + * Ignored when this when *input_color_proto_mask* set to zero.
> + */
> + enum rte_color default_input_color;
> };
>
> /**
> @@ -417,6 +520,16 @@ struct rte_mtr_capabilities {
> * @see enum rte_mtr_stats_type
> */
> uint64_t stats_mask;
> +
> + /** Set of supported input color protocol.
> + * @see enum rte_mtr_color_in_protocol
> + */
> + uint64_t input_color_proto_mask;
> +
> + /** When non-zero, it indicates that driver supports separate
> + * input color table for given ethdev port.
> + */
> + int separate_input_color_table_per_port;
> };
>
> /**
> @@ -832,6 +945,59 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
> enum rte_color *dscp_table,
> struct rte_mtr_error *error);
>
> +/**
> + * MTR object VLAN table update
> + *
> + * @param[in] port_id
> + * The port identifier of the Ethernet device.
> + * @param[in] mtr_id
> + * MTR object ID. Needs to be valid.
> + * @param[in] vlan_table
> + * When non-NULL: it points to a pre-allocated and pre-populated table with
> + * exactly 16 elements providing the input color for each value of the
> + * each value of the DEI(1bit), PCP(3 bits) input packet field.
> + * When NULL: it is equivalent to setting this parameter to an "all-green"
> + * populated table (i.e. table with all the 16 elements set to green color).
> + * @param[out] error
> + * Error details. Filled in only on error, when not NULL.
> + * @return
> + * 0 on success, non-zero error code otherwise.
> + */
> +__rte_experimental
> +int
> +rte_mtr_meter_vlan_table_update(uint16_t port_id, uint32_t mtr_id,
> + enum rte_color *vlan_table,
> + struct rte_mtr_error *error);
> +/**
> + * Set the priority for input color protocol
> + *
> + * When multiple bits set in struct rte_mtr_params::input_color_proto_mask
> + * then this API shall be used to set the priority, in the order, in
> + * which protocol to be used to find the input color.
> + *
> + * @param[in] port_id
> + * The port identifier of the Ethernet device.
> + * @param[in] mtr_id
> + * MTR object ID. Needs to be valid.
> + * @param[in] proto
> + * Input color protocol to apply priority.
> + * MTR object's *input_color_proto_mask* should be configured
> + * with proto value.
> + * @param[in] priority
> + * Input color protocol priority. Value zero indicates
> + * the highest priority.
> + * @param[out] error
> + * Error details. Filled in only on error, when not NULL.
> + * @return
> + * 0 on success, non-zero error code otherwise.
> + *
> + * @see rte_mtr_params::input_color_proto_mask
> + */
> +__rte_experimental
> +int
> +rte_mtr_color_in_protocol_priority_set(uint16_t port_id, uint32_t mtr_id,
> + enum rte_mtr_color_in_protocol proto, uint32_t priority,
> + struct rte_mtr_error *error);
> /**
> * MTR object enabled statistics counters update
> *
> diff --git a/lib/ethdev/rte_mtr_driver.h b/lib/ethdev/rte_mtr_driver.h
> index ee8c6ef7ad..827952adc6 100644
> --- a/lib/ethdev/rte_mtr_driver.h
> +++ b/lib/ethdev/rte_mtr_driver.h
> @@ -97,6 +97,19 @@ typedef int (*rte_mtr_meter_dscp_table_update_t)(struct rte_eth_dev *dev,
> enum rte_color *dscp_table,
> struct rte_mtr_error *error);
>
> +/** @internal mtr object meter vlan table update. */
> +typedef int (*rte_mtr_meter_vlan_table_update_t)(struct rte_eth_dev *dev,
> + uint32_t mtr_id,
> + enum rte_color *vlan_table,
> + struct rte_mtr_error *error);
> +
> +/** @internal Set the priority for input color protocol on MTR object. */
> +typedef int (*rte_mtr_meter_color_in_proto_prio_set_t)(struct rte_eth_dev *dev,
> + uint32_t mtr_id,
> + enum rte_mtr_color_in_protocol proto,
> + uint32_t priority,
> + struct rte_mtr_error *error);
> +
> /** @internal MTR object enabled stats update. */
> typedef int (*rte_mtr_stats_update_t)(struct rte_eth_dev *dev,
> uint32_t mtr_id,
> @@ -139,6 +152,12 @@ struct rte_mtr_ops {
> /** MTR object meter DSCP table update */
> rte_mtr_meter_dscp_table_update_t meter_dscp_table_update;
>
> + /** MTR object meter VLAN table update */
> + rte_mtr_meter_vlan_table_update_t meter_vlan_table_update;
> +
> + /** Set the priority for input color protocol on MTR object. */
> + rte_mtr_meter_color_in_proto_prio_set_t in_proto_prio_set;
> +
> /** MTR object enabled stats update */
> rte_mtr_stats_update_t stats_update;
>
> diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
> index 20391ab29e..cccbf6dee5 100644
> --- a/lib/ethdev/version.map
> +++ b/lib/ethdev/version.map
> @@ -279,6 +279,10 @@ EXPERIMENTAL {
> rte_flow_async_action_handle_create;
> rte_flow_async_action_handle_destroy;
> rte_flow_async_action_handle_update;
> +
> + # added in 22.07
Symbols are not in alphabetical order.
> + rte_mtr_meter_vlan_table_update;
> + rte_mtr_color_in_protocol_priority_set;
> };
>
> INTERNAL {
--
Regards, Ray K
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based input color selection
2022-04-21 18:02 ` [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based " jerinj
2022-04-26 10:19 ` Ray Kinsella
@ 2022-04-26 12:08 ` Dumitrescu, Cristian
2022-05-01 12:56 ` Jerin Jacob
2022-05-01 14:46 ` [dpdk-dev] [PATCH v5] " jerinj
2 siblings, 1 reply; 30+ messages in thread
From: Dumitrescu, Cristian @ 2022-04-26 12:08 UTC (permalink / raw)
To: jerinj, dev, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko,
Ray Kinsella
Cc: ajit.khaparde, aboyer, Xing, Beilei, Richardson, Bruce, chas3,
Xia, Chenbo, Loftus, Ciara, dsinghrawat, ed.czeck, evgenys,
grive, g.singh, zhouguoyang, Wang, Haiyue, hkalra, heinrich.kuhn,
hemant.agrawal, hyonkim, igorch, irusskikh, jgrajcia, Singh,
Jasvinder, jianwang, jiawenwu, Wu, Jingjing, Daley, John,
john.miller, linville, Wiles, Keith, kirankumark, oulijun,
lironh, longli, mw, spinler, matan, Peters, Matt,
maxime.coquelin, mk, humin29, pnalla, ndabilpuram, Yang, Qiming,
Zhang, Qi Z, radhac, rahul.lakkireddy, rmody, Xu, Rosen,
sachin.saxena, skoteshwar, shshaikh, shaibran, Shepard Siegel,
asomalap, somnath.kotur, sthemmin, Webster, Steven, skori,
mtetsuyah, vburru, viacheslavo, Wang, Xiao W, cloud.wangxiaoyun,
yisen.zhuang, Wang, Yong, xuanziyang2
Hi Jerin,
Thank you for implementing according to our agreement, I am happy to see that we are converging.
Here are some comments below:
<snip>
> diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h
> index 40df0888c8..76ffbcf724 100644
> --- a/lib/ethdev/rte_mtr.h
> +++ b/lib/ethdev/rte_mtr.h
> @@ -213,6 +213,52 @@ struct rte_mtr_meter_policy_params {
> const struct rte_flow_action *actions[RTE_COLORS];
> };
>
> +/**
> + * Input color protocol method
I suggest adding some more explanations here:
More than one method can be enabled for a given meter. Even if enabled, a method might not be applicable to each input packet, in case the associated protocol header is not present in the packet. The highest priority method that is both enabled for the meter and also applicable for the current input packet wins; if none is both enabled and applicable, the default input color is used. @see function rte_mtr_color_in_protocol_priority_set()
> + */
> +enum rte_mtr_color_in_protocol {
> + /**
> + * If the input packet has at least one VLAN label, its input color is
> + * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
> + * indexing into the struct rte_mtr_params::vlan_table.
> + * Otherwise, the *default_input_color* is applied.
> + *
The statement "Otherwise, the *default_input_color* is applied" is incorrect IMO and should be removed, as multiple methods might be enabled and also applicable to a specific input packet, in which case the highest priority method wins, as opposed to the default input color.
I suggest a simplification "Enable the detection of the packet input color based on the outermost VLAN header fields DEI (1 bit) and PCP (3 bits). These fields are used as index into the VLAN table"
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::vlan_table
> + */
> + RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN = RTE_BIT64(0),
> + /**
> + * If the input packet has at least one VLAN label, its input color is
> + * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
> + * indexing into the struct rte_mtr_params::vlan_table.
> + * Otherwise, the *default_input_color* is applied.
> + *
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::vlan_table
> + */
Same simplification suggested here.
> + RTE_MTR_COLOR_IN_PROTO_INNER_VLAN = RTE_BIT64(1),
> + /**
> + * If the input packet is IPv4 or IPv6, its input color is detected by
> + * the outermost DSCP field indexing into the
> + * struct rte_mtr_params::dscp_table.
> + * Otherwise, the *default_input_color* is applied.
> + *
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::dscp_table
> + */
Same simplification suggested here.
> + RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP = RTE_BIT64(2),
I am OK to keep DSCP for the name of the table instead of renaming the table, as you suggested, but this method name should reflect the protocol, not the field: RTE_MTR_COLOR_IN_PROTO_OUTER_IP.
> + /**
> + * If the input packet is IPv4 or IPv6, its input color is detected by
> + * the innermost DSCP field indexing into the
> + * struct rte_mtr_params::dscp_table.
> + * Otherwise, the *default_input_color* is applied.
> + *
> + * @see struct rte_mtr_params::default_input_color
> + * @see struct rte_mtr_params::dscp_table
> + */
Same simplification suggested here.
> + RTE_MTR_COLOR_IN_PROTO_INNER_DSCP = RTE_BIT64(3),
I am OK to keep DSCP for the name of the table instead of renaming the table, as you suggested, but this method name should reflect the protocol, not the field: RTE_MTR_COLOR_IN_PROTO_INNER_IP.
> +
> /**
> * Parameters for each traffic metering & policing object
> *
> @@ -233,20 +279,58 @@ struct rte_mtr_params {
> */
> int use_prev_mtr_color;
>
> - /** Meter input color. When non-NULL: it points to a pre-allocated and
> + /** Meter input color based on IP DSCP protocol field.
> + *
> + * Valid when *input_color_proto_mask* set to any of the following
> + * RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP,
> + * RTE_MTR_COLOR_IN_PROTO_INNER_DSCP
> + *
> + * When non-NULL: it points to a pre-allocated and
> * pre-populated table with exactly 64 elements providing the input
> * color for each value of the IPv4/IPv6 Differentiated Services Code
> - * Point (DSCP) input packet field. When NULL: it is equivalent to
> - * setting this parameter to an all-green populated table (i.e. table
> - * with all the 64 elements set to green color). The color blind mode
> - * is configured by setting *use_prev_mtr_color* to 0 and *dscp_table*
> - * to either NULL or to an all-green populated table. When
> - * *use_prev_mtr_color* is non-zero value or when *dscp_table*
> contains
> - * at least one yellow or red color element, then the color aware mode
> - * is configured.
> + * Point (DSCP) input packet field.
> + *
> + * When NULL: it is equivalent to setting this parameter to an all-green
> + * populated table (i.e. table with all the 64 elements set to green
> + * color). The color blind mode is configured by setting
> + * *use_prev_mtr_color* to 0 and *dscp_table* to either NULL or to an
> + * all-green populated table.
> + *
> + * When *use_prev_mtr_color* is non-zero value or when
> *dscp_table*
> + * contains at least one yellow or red color element, then the color
> + * aware mode is configured.
> + *
> + * @see enum
> rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP
> + * @see enum
> rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_DSCP
> + * @see struct rte_mtr_params::input_color_proto_mask
> */
> enum rte_color *dscp_table;
> -
> + /** Meter input color based on VLAN DEI(1bit), PCP(3 bits) protocol
> + * fields.
> + *
> + * Valid when *input_color_proto_mask* set to any of the following
> + * RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN,
> + * RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
> + *
> + * When non-NULL: it points to a pre-allocated and pre-populated
> + * table with exactly 16 elements providing the input color for
> + * each value of the DEI(1bit), PCP(3 bits) input packet field.
> + *
> + * When NULL: it is equivalent to setting this parameter to an
> + * all-green populated table (i.e. table with
> + * all the 16 elements set to green color). The color blind mode
> + * is configured by setting *use_prev_mtr_color* to 0 and
> + * *vlan_table* to either NULL or to an all-green populated table.
> + *
> + * When *use_prev_mtr_color* is non-zero value
> + * or when *vlan_table* contains at least one yellow or
> + * red color element, then the color aware mode is configured.
> + *
> + * @see enum
> rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN
> + * @see enum
> rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
> + * @see struct rte_mtr_params::input_color_proto_mask
> + */
> + enum rte_color *vlan_table;
> /** Non-zero to enable the meter, zero to disable the meter at the
> time
> * of MTR object creation. Ignored when the meter profile indicated by
> * *meter_profile_id* is set to NONE.
> @@ -261,6 +345,25 @@ struct rte_mtr_params {
>
> /** Meter policy ID. @see rte_mtr_meter_policy_add() */
> uint32_t meter_policy_id;
> +
> + /** Set of input color protocols to be enabled.
> + *
> + * Set value to zero to configure as color blind mode.
> + *
> + * When multiple bits set then rte_mtr_color_in_protocol_priority_set()
> + * shall be used to set the priority, in the order, in which protocol
> + * to be used to find the inpput color.
> + *
> + * @see enum rte_mtr_color_in_protocol
> + * @see rte_mtr_color_in_protocol_priority_set()
> + */
> + uint64_t input_color_proto_mask;
We should not have this as an input parameter at all, please remove this field. This mask is implicitly created by the user by calling the rte_mtr_color_in_protocol_priority_set() API function. If this function is called for a given method, then that method is enabled with the given priority; when this function is not called for a given method, then that method is disabled.
> +
> + /** Input color to be set for the input packet when none of the
> + * enabled input color methods is applicable to the input packet.
> + * Ignored when this when *input_color_proto_mask* set to zero.
> + */
> + enum rte_color default_input_color;
> };
>
> /**
> @@ -417,6 +520,16 @@ struct rte_mtr_capabilities {
> * @see enum rte_mtr_stats_type
> */
> uint64_t stats_mask;
> +
> + /** Set of supported input color protocol.
> + * @see enum rte_mtr_color_in_protocol
> + */
> + uint64_t input_color_proto_mask;
Agree.
> +
> + /** When non-zero, it indicates that driver supports separate
> + * input color table for given ethdev port.
> + */
> + int separate_input_color_table_per_port;
The input color tables are actually configured per meter object, do we also need a "separate_input_color_table_per_meter" capability flag?
> };
>
> /**
> @@ -832,6 +945,59 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
> enum rte_color *dscp_table,
> struct rte_mtr_error *error);
>
> +/**
> + * MTR object VLAN table update
> + *
> + * @param[in] port_id
> + * The port identifier of the Ethernet device.
> + * @param[in] mtr_id
> + * MTR object ID. Needs to be valid.
> + * @param[in] vlan_table
> + * When non-NULL: it points to a pre-allocated and pre-populated table with
> + * exactly 16 elements providing the input color for each value of the
> + * each value of the DEI(1bit), PCP(3 bits) input packet field.
> + * When NULL: it is equivalent to setting this parameter to an "all-green"
> + * populated table (i.e. table with all the 16 elements set to green color).
> + * @param[out] error
> + * Error details. Filled in only on error, when not NULL.
> + * @return
> + * 0 on success, non-zero error code otherwise.
> + */
> +__rte_experimental
> +int
> +rte_mtr_meter_vlan_table_update(uint16_t port_id, uint32_t mtr_id,
> + enum rte_color *vlan_table,
> + struct rte_mtr_error *error);
> +/**
> + * Set the priority for input color protocol
> + *
> + * When multiple bits set in struct rte_mtr_params::input_color_proto_mask
> + * then this API shall be used to set the priority, in the order, in
> + * which protocol to be used to find the input color.
As stated above, we should remove struct rte_mtr_params::input_color_proto_mask, as it is build implicitly by calling this function.
I suggest reiterating the explanation from above:
More than one method can be enabled for a given meter. Even if enabled, a method might not be applicable to each input packet, in case the associated protocol header is not present in the packet. The highest priority method that is both enabled for the meter and also applicable for the current input packet wins; if none is both enabled and applicable, the default input color is used. @see function rte_mtr_color_in_protocol_priority_set()
> + *
> + * @param[in] port_id
> + * The port identifier of the Ethernet device.
> + * @param[in] mtr_id
> + * MTR object ID. Needs to be valid.
> + * @param[in] proto
> + * Input color protocol to apply priority.
> + * MTR object's *input_color_proto_mask* should be configured
> + * with proto value.
> + * @param[in] priority
> + * Input color protocol priority. Value zero indicates
> + * the highest priority.
Agree.
> + * @param[out] error
> + * Error details. Filled in only on error, when not NULL.
> + * @return
> + * 0 on success, non-zero error code otherwise.
> + *
> + * @see rte_mtr_params::input_color_proto_mask
> + */
> +__rte_experimental
> +int
> +rte_mtr_color_in_protocol_priority_set(uint16_t port_id, uint32_t mtr_id,
> + enum rte_mtr_color_in_protocol proto, uint32_t priority,
> + struct rte_mtr_error *error);
> /**
> * MTR object enabled statistics counters update
> *
<snip>
Regards,
Cristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based input color selection
2022-04-26 10:19 ` Ray Kinsella
@ 2022-05-01 12:52 ` Jerin Jacob
0 siblings, 0 replies; 30+ messages in thread
From: Jerin Jacob @ 2022-05-01 12:52 UTC (permalink / raw)
To: Ray Kinsella
Cc: Jerin Jacob, dpdk-dev, Cristian Dumitrescu, Thomas Monjalon,
Ferruh Yigit, Andrew Rybchenko, Ajit Khaparde, Andrew Boyer,
Beilei Xing, Richardson, Bruce, Chas Williams, Xia, Chenbo,
Ciara Loftus, Devendra Singh Rawat, Ed Czeck, Evgeny Schemeilin,
Gaetan Rivet, Gagandeep Singh, Guoyang Zhou, Haiyue Wang,
Harman Kalra, heinrich.kuhn, Hemant Agrawal, Hyong Youb Kim,
Igor Chauskin, Igor Russkikh, Jakub Grajciar, Jasvinder Singh,
Jian Wang, Jiawen Wu, Jingjing Wu, John Daley, John Miller,
John W. Linville, Wiles, Keith, Kiran Kumar K, Lijun Ou,
Liron Himi, Long Li, Marcin Wojtas, Martin Spinler, Matan Azrad,
Matt Peters, Maxime Coquelin, Michal Krawczyk, Min Hu (Connor,
Pradeep Kumar Nalla, Nithin Dabilpuram, Qiming Yang, Qi Zhang,
Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
Rosen Xu, Sachin Saxena, Satha Koteswara Rao Kottidi,
Shahed Shaikh, Shai Brandes, Shepard Siegel,
Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
Veerasenareddy Burru, Viacheslav Ovsiienko, Xiao Wang,
Xiaoyun Wang, Yisen Zhuang, Yong Wang, Ziyang Xuan
On Tue, Apr 26, 2022 at 3:49 PM Ray Kinsella <mdr@ashroe.eu> wrote:
>
>
> jerinj@marvell.com writes:
>
> > From: Jerin Jacob <jerinj@marvell.com>
> >
> > Currently, meter object supports only DSCP based on input color table,
> > The patch enhance that to support VLAN based input color table,
> > color table based on inner field for the tunnel use case, and
> > support for fallback color per meter if packet based on a different field.
> >
> > All of the above features are exposed through capability and added
> > additional capability to specify the implementation supports
> > more than one input color table per ethdev port.
> >
> > Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> > Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> > ---
> > v4..v3:
> >
> > - Aligned with community meeting call which is documented in
> > https://patches.dpdk.org/project/dpdk/patch/20220301085824.1041009-1-skori@marvell.com/
> > as last message. With following exception,
> > - Used RTE_MTR_COLOR_IN_*_DSCP instead of RTE_MTR_COLOR_IN_*_IP as
> > there is already dscp_table and rte_mtr_meter_dscp_table_update() API.
> > Changing above symbols break existing application for no good.
> > - Updated 22.07 release notes
> > - Remove testpmd changes from series to finalize the API spec first and
> > then we can send testpmd changes.
> >
> > v3..v2:
> >
> > - Fix input color flags as a bitmask
> > - Add definitions for newly added API
> >
> > v2..v1:
> > - Fix seperate typo
> >
> > v1..RFC:
> >
> > Address the review comments by Cristian at
> > https://patches.dpdk.org/project/dpdk/patch/20210820082401.3778736-1-jerinj@marvell.com/
> >
> > diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
> > index 20391ab29e..cccbf6dee5 100644
> > --- a/lib/ethdev/version.map
> > +++ b/lib/ethdev/version.map
> > @@ -279,6 +279,10 @@ EXPERIMENTAL {
> > rte_flow_async_action_handle_create;
> > rte_flow_async_action_handle_destroy;
> > rte_flow_async_action_handle_update;
> > +
> > + # added in 22.07
>
> Symbols are not in alphabetical order.
Thanks. Will fix it in v5
>
> > + rte_mtr_meter_vlan_table_update;
> > + rte_mtr_color_in_protocol_priority_set;
> > };
> >
> > INTERNAL {
>
>
> --
> Regards, Ray K
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based input color selection
2022-04-26 12:08 ` Dumitrescu, Cristian
@ 2022-05-01 12:56 ` Jerin Jacob
0 siblings, 0 replies; 30+ messages in thread
From: Jerin Jacob @ 2022-05-01 12:56 UTC (permalink / raw)
To: Dumitrescu, Cristian
Cc: jerinj, dev, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko,
Ray Kinsella, ajit.khaparde, aboyer, Xing, Beilei, Richardson,
Bruce, chas3, Xia, Chenbo, Loftus, Ciara, dsinghrawat, ed.czeck,
evgenys, grive, g.singh, zhouguoyang, Wang, Haiyue, hkalra,
heinrich.kuhn, hemant.agrawal, hyonkim, igorch, irusskikh,
jgrajcia, Singh, Jasvinder, jianwang, jiawenwu, Wu, Jingjing,
Daley, John, john.miller, linville, Wiles, Keith, kirankumark,
oulijun, lironh, longli, mw, spinler, matan, Peters, Matt,
maxime.coquelin, mk, humin29, pnalla, ndabilpuram, Yang, Qiming,
Zhang, Qi Z, radhac, rahul.lakkireddy, rmody, Xu, Rosen,
sachin.saxena, skoteshwar, shshaikh, shaibran, Shepard Siegel,
asomalap, somnath.kotur, sthemmin, Webster, Steven, skori,
mtetsuyah, vburru, viacheslavo, Wang, Xiao W, cloud.wangxiaoyun,
yisen.zhuang, Wang, Yong, xuanziyang2
On Tue, Apr 26, 2022 at 5:38 PM Dumitrescu, Cristian
<cristian.dumitrescu@intel.com> wrote:
>
> Hi Jerin,
Hi Cristian
>
> Thank you for implementing according to our agreement, I am happy to see that we are converging.
:-)
>
> Here are some comments below:
>
> <snip>
>
> > diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h
> > index 40df0888c8..76ffbcf724 100644
> > --- a/lib/ethdev/rte_mtr.h
> > +++ b/lib/ethdev/rte_mtr.h
> > @@ -213,6 +213,52 @@ struct rte_mtr_meter_policy_params {
> > const struct rte_flow_action *actions[RTE_COLORS];
> > };
> >
> > +/**
> > + * Input color protocol method
>
> I suggest adding some more explanations here:
> More than one method can be enabled for a given meter. Even if enabled, a method might not be applicable to each input packet, in case the associated protocol header is not present in the packet. The highest priority method that is both enabled for the meter and also applicable for the current input packet wins; if none is both enabled and applicable, the default input color is used. @see function rte_mtr_color_in_protocol_priority_set()
OK.
>
> > + */
> > +enum rte_mtr_color_in_protocol {
> > + /**
> > + * If the input packet has at least one VLAN label, its input color is
> > + * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
> > + * indexing into the struct rte_mtr_params::vlan_table.
> > + * Otherwise, the *default_input_color* is applied.
> > + *
>
> The statement "Otherwise, the *default_input_color* is applied" is incorrect IMO and should be removed, as multiple methods might be enabled and also applicable to a specific input packet, in which case the highest priority method wins, as opposed to the default input color.
>
> I suggest a simplification "Enable the detection of the packet input color based on the outermost VLAN header fields DEI (1 bit) and PCP (3 bits). These fields are used as index into the VLAN table"
OK
>
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::vlan_table
> > + */
> > + RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN = RTE_BIT64(0),
> > + /**
> > + * If the input packet has at least one VLAN label, its input color is
> > + * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
> > + * indexing into the struct rte_mtr_params::vlan_table.
> > + * Otherwise, the *default_input_color* is applied.
> > + *
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::vlan_table
> > + */
>
> Same simplification suggested here.
OK
>
> > + RTE_MTR_COLOR_IN_PROTO_INNER_VLAN = RTE_BIT64(1),
> > + /**
> > + * If the input packet is IPv4 or IPv6, its input color is detected by
> > + * the outermost DSCP field indexing into the
> > + * struct rte_mtr_params::dscp_table.
> > + * Otherwise, the *default_input_color* is applied.
> > + *
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::dscp_table
> > + */
>
> Same simplification suggested here.
OK
>
> > + RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP = RTE_BIT64(2),
>
> I am OK to keep DSCP for the name of the table instead of renaming the table, as you suggested, but this method name should reflect the protocol, not the field: RTE_MTR_COLOR_IN_PROTO_OUTER_IP.
OK
>
> > + /**
> > + * If the input packet is IPv4 or IPv6, its input color is detected by
> > + * the innermost DSCP field indexing into the
> > + * struct rte_mtr_params::dscp_table.
> > + * Otherwise, the *default_input_color* is applied.
> > + *
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::dscp_table
> > + */
>
> Same simplification suggested here.
OK
>
> > + RTE_MTR_COLOR_IN_PROTO_INNER_DSCP = RTE_BIT64(3),
>
> I am OK to keep DSCP for the name of the table instead of renaming the table, as you suggested, but this method name should reflect the protocol, not the field: RTE_MTR_COLOR_IN_PROTO_INNER_IP.
OK
>
> > +
> > /**
> > * Parameters for each traffic metering & policing object
> > *
> > @@ -233,20 +279,58 @@ struct rte_mtr_params {
> > */
> > int use_prev_mtr_color;
> >
> > - /** Meter input color. When non-NULL: it points to a pre-allocated and
> > + /** Meter input color based on IP DSCP protocol field.
> > + *
> > + * Valid when *input_color_proto_mask* set to any of the following
> > + * RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP,
> > + * RTE_MTR_COLOR_IN_PROTO_INNER_DSCP
> > + *
> > + * When non-NULL: it points to a pre-allocated and
> > * pre-populated table with exactly 64 elements providing the input
> > * color for each value of the IPv4/IPv6 Differentiated Services Code
> > - * Point (DSCP) input packet field. When NULL: it is equivalent to
> > - * setting this parameter to an all-green populated table (i.e. table
> > - * with all the 64 elements set to green color). The color blind mode
> > - * is configured by setting *use_prev_mtr_color* to 0 and *dscp_table*
> > - * to either NULL or to an all-green populated table. When
> > - * *use_prev_mtr_color* is non-zero value or when *dscp_table*
> > contains
> > - * at least one yellow or red color element, then the color aware mode
> > - * is configured.
> > + * Point (DSCP) input packet field.
> > + *
> > + * When NULL: it is equivalent to setting this parameter to an all-green
> > + * populated table (i.e. table with all the 64 elements set to green
> > + * color). The color blind mode is configured by setting
> > + * *use_prev_mtr_color* to 0 and *dscp_table* to either NULL or to an
> > + * all-green populated table.
> > + *
> > + * When *use_prev_mtr_color* is non-zero value or when
> > *dscp_table*
> > + * contains at least one yellow or red color element, then the color
> > + * aware mode is configured.
> > + *
> > + * @see enum
> > rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP
> > + * @see enum
> > rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_DSCP
> > + * @see struct rte_mtr_params::input_color_proto_mask
> > */
> > enum rte_color *dscp_table;
> > -
> > + /** Meter input color based on VLAN DEI(1bit), PCP(3 bits) protocol
> > + * fields.
> > + *
> > + * Valid when *input_color_proto_mask* set to any of the following
> > + * RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN,
> > + * RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
> > + *
> > + * When non-NULL: it points to a pre-allocated and pre-populated
> > + * table with exactly 16 elements providing the input color for
> > + * each value of the DEI(1bit), PCP(3 bits) input packet field.
> > + *
> > + * When NULL: it is equivalent to setting this parameter to an
> > + * all-green populated table (i.e. table with
> > + * all the 16 elements set to green color). The color blind mode
> > + * is configured by setting *use_prev_mtr_color* to 0 and
> > + * *vlan_table* to either NULL or to an all-green populated table.
> > + *
> > + * When *use_prev_mtr_color* is non-zero value
> > + * or when *vlan_table* contains at least one yellow or
> > + * red color element, then the color aware mode is configured.
> > + *
> > + * @see enum
> > rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN
> > + * @see enum
> > rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
> > + * @see struct rte_mtr_params::input_color_proto_mask
> > + */
> > + enum rte_color *vlan_table;
> > /** Non-zero to enable the meter, zero to disable the meter at the
> > time
> > * of MTR object creation. Ignored when the meter profile indicated by
> > * *meter_profile_id* is set to NONE.
> > @@ -261,6 +345,25 @@ struct rte_mtr_params {
> >
> > /** Meter policy ID. @see rte_mtr_meter_policy_add() */
> > uint32_t meter_policy_id;
> > +
> > + /** Set of input color protocols to be enabled.
> > + *
> > + * Set value to zero to configure as color blind mode.
> > + *
> > + * When multiple bits set then rte_mtr_color_in_protocol_priority_set()
> > + * shall be used to set the priority, in the order, in which protocol
> > + * to be used to find the inpput color.
> > + *
> > + * @see enum rte_mtr_color_in_protocol
> > + * @see rte_mtr_color_in_protocol_priority_set()
> > + */
> > + uint64_t input_color_proto_mask;
>
> We should not have this as an input parameter at all, please remove this field. This mask is implicitly created by the user by calling the rte_mtr_color_in_protocol_priority_set() API function. If this function is called for a given method, then that method is enabled with the given priority; when this function is not called for a given method, then that method is disabled.
OK. Since we had rte_mtr_color_in_protocol_priority_set(), I was
thinking it is only setting "priority".
I will change to rte_mtr_color_in_protocol_set() and add API to _get() as well.
>
> > +
> > + /** Input color to be set for the input packet when none of the
> > + * enabled input color methods is applicable to the input packet.
> > + * Ignored when this when *input_color_proto_mask* set to zero.
> > + */
> > + enum rte_color default_input_color;
> > };
> >
> > /**
> > @@ -417,6 +520,16 @@ struct rte_mtr_capabilities {
> > * @see enum rte_mtr_stats_type
> > */
> > uint64_t stats_mask;
> > +
> > + /** Set of supported input color protocol.
> > + * @see enum rte_mtr_color_in_protocol
> > + */
> > + uint64_t input_color_proto_mask;
>
> Agree.
>
> > +
> > + /** When non-zero, it indicates that driver supports separate
> > + * input color table for given ethdev port.
> > + */
> > + int separate_input_color_table_per_port;
>
> The input color tables are actually configured per meter object, do we also need a "separate_input_color_table_per_meter" capability flag?
Yes. We have a similar limitation.
>
> > };
> >
> > /**
> > @@ -832,6 +945,59 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
> > enum rte_color *dscp_table,
> > struct rte_mtr_error *error);
> >
> > +/**
> > + * MTR object VLAN table update
> > + *
> > + * @param[in] port_id
> > + * The port identifier of the Ethernet device.
> > + * @param[in] mtr_id
> > + * MTR object ID. Needs to be valid.
> > + * @param[in] vlan_table
> > + * When non-NULL: it points to a pre-allocated and pre-populated table with
> > + * exactly 16 elements providing the input color for each value of the
> > + * each value of the DEI(1bit), PCP(3 bits) input packet field.
> > + * When NULL: it is equivalent to setting this parameter to an "all-green"
> > + * populated table (i.e. table with all the 16 elements set to green color).
> > + * @param[out] error
> > + * Error details. Filled in only on error, when not NULL.
> > + * @return
> > + * 0 on success, non-zero error code otherwise.
> > + */
> > +__rte_experimental
> > +int
> > +rte_mtr_meter_vlan_table_update(uint16_t port_id, uint32_t mtr_id,
> > + enum rte_color *vlan_table,
> > + struct rte_mtr_error *error);
> > +/**
> > + * Set the priority for input color protocol
> > + *
> > + * When multiple bits set in struct rte_mtr_params::input_color_proto_mask
> > + * then this API shall be used to set the priority, in the order, in
> > + * which protocol to be used to find the input color.
>
> As stated above, we should remove struct rte_mtr_params::input_color_proto_mask, as it is build implicitly by calling this function.
>
> I suggest reiterating the explanation from above:
> More than one method can be enabled for a given meter. Even if enabled, a method might not be applicable to each input packet, in case the associated protocol header is not present in the packet. The highest priority method that is both enabled for the meter and also applicable for the current input packet wins; if none is both enabled and applicable, the default input color is used. @see function rte_mtr_color_in_protocol_priority_set()
OK
>
> > + *
> > + * @param[in] port_id
> > + * The port identifier of the Ethernet device.
> > + * @param[in] mtr_id
> > + * MTR object ID. Needs to be valid.
> > + * @param[in] proto
> > + * Input color protocol to apply priority.
> > + * MTR object's *input_color_proto_mask* should be configured
> > + * with proto value.
> > + * @param[in] priority
> > + * Input color protocol priority. Value zero indicates
> > + * the highest priority.
>
> Agree.
>
> > + * @param[out] error
> > + * Error details. Filled in only on error, when not NULL.
> > + * @return
> > + * 0 on success, non-zero error code otherwise.
> > + *
> > + * @see rte_mtr_params::input_color_proto_mask
> > + */
> > +__rte_experimental
> > +int
> > +rte_mtr_color_in_protocol_priority_set(uint16_t port_id, uint32_t mtr_id,
> > + enum rte_mtr_color_in_protocol proto, uint32_t priority,
> > + struct rte_mtr_error *error);
> > /**
> > * MTR object enabled statistics counters update
> > *
>
> <snip>
>
> Regards,
> Cristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* [dpdk-dev] [PATCH v5] ethdev: mtr: support protocol based input color selection
2022-04-21 18:02 ` [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based " jerinj
2022-04-26 10:19 ` Ray Kinsella
2022-04-26 12:08 ` Dumitrescu, Cristian
@ 2022-05-01 14:46 ` jerinj
2022-05-04 8:52 ` Ray Kinsella
` (2 more replies)
2 siblings, 3 replies; 30+ messages in thread
From: jerinj @ 2022-05-01 14:46 UTC (permalink / raw)
To: dev, Cristian Dumitrescu, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko, Ray Kinsella
Cc: ajit.khaparde, aboyer, beilei.xing, bruce.richardson, chas3,
chenbo.xia, ciara.loftus, dsinghrawat, ed.czeck, evgenys, grive,
g.singh, zhouguoyang, haiyue.wang, hkalra, heinrich.kuhn,
hemant.agrawal, hyonkim, igorch, irusskikh, jgrajcia,
jasvinder.singh, jianwang, jiawenwu, jingjing.wu, johndale,
john.miller, linville, keith.wiles, kirankumark, oulijun, lironh,
longli, mw, spinler, matan, matt.peters, maxime.coquelin, mk,
humin29, pnalla, ndabilpuram, qiming.yang, qi.z.zhang, radhac,
rahul.lakkireddy, rmody, rosen.xu, sachin.saxena, skoteshwar,
shshaikh, shaibran, shepard.siegel, asomalap, somnath.kotur,
sthemmin, steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2, Jerin Jacob
From: Jerin Jacob <jerinj@marvell.com>
Currently, meter object supports only DSCP based on input color table,
The patch enhance that to support VLAN based input color table,
color table based on inner field for the tunnel use case, and
support for fallback color per meter if packet based on a different field.
All of the above features are exposed through capability and added
additional capability to specify the implementation supports
more than one input color table per ethdev port.
Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---
v5..v4:
- Improved the Doxgen comments as per
http://patches.dpdk.org/project/dpdk/patch/20220421180241.514767-1-jerinj@marvell.com/
- Removed input_color_proto_mask
- Renamed rte_mtr_color_in_protocol_priority_set() to rte_mtr_color_in_protocol_set()
- Introduced rte_mtr_color_in_protocol_get(), rte_mtr_color_in_protocol_priority_get()
for getting the configured input color protocol.
v4..v3:
- Aligned with community meeting call which is documented in
https://patches.dpdk.org/project/dpdk/patch/20220301085824.1041009-1-skori@marvell.com/
as last message. With following exception,
- Used RTE_MTR_COLOR_IN_*_DSCP instead of RTE_MTR_COLOR_IN_*_IP as
there is already dscp_table and rte_mtr_meter_dscp_table_update() API.
Changing above symbols break existing application for no good.
- Updated 22.07 release notes
- Remove testpmd changes from series to finalize the API spec first and
then we can send testpmd changes.
v3..v2:
- Fix input color flags as a bitmask
- Add definitions for newly added API
v2..v1:
- Fix seperate typo
v1..RFC:
Address the review comments by Cristian at
https://patches.dpdk.org/project/dpdk/patch/20210820082401.3778736-1-jerinj@marvell.com/
.../traffic_metering_and_policing.rst | 35 +++
doc/guides/rel_notes/release_22_07.rst | 10 +
lib/ethdev/rte_mtr.c | 50 ++++
lib/ethdev/rte_mtr.h | 216 +++++++++++++++++-
lib/ethdev/rte_mtr_driver.h | 38 +++
lib/ethdev/version.map | 6 +
6 files changed, 345 insertions(+), 10 deletions(-)
diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst
index ceb5a96488..d1958a023d 100644
--- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
+++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
@@ -21,6 +21,7 @@ The main features are:
* Policer actions (per meter output color): recolor, drop
* Statistics (per policer output color)
* Chaining multiple meter objects
+* Protocol based input color selection
Configuration steps
-------------------
@@ -105,3 +106,37 @@ traffic meter and policing library.
* Adding one (or multiple) actions of the type ``RTE_FLOW_ACTION_TYPE_METER``
to the list of meter actions (``struct rte_mtr_meter_policy_params::actions``)
specified per color as show in :numref:`figure_rte_mtr_chaining`.
+
+Protocol based input color selection
+------------------------------------
+
+The API supports selecting the input color based on the packet content.
+Following is the API usage model for the same.
+
+#. Probe the protocol based input color selection device capabilities using
+ the following parameters with ``rte_mtr_capabilities_get()`` API.
+
+ * ``struct rte_mtr_capabilities::input_color_proto_mask;``
+ * ``struct rte_mtr_capabilities::separate_input_color_table_per_port``
+
+#. When creating the meter object using ``rte_mtr_create()``, configure
+ relevant input color selection parameters such as
+
+ * Fill the tables ``struct rte_mtr_params::dscp_table``,
+ ``struct rte_mtr_params::vlan_table`` based on input color selected.
+
+ * Update the ``struct rte_mtr_params::default_input_color`` to determine
+ the default input color in case the input packet does not match
+ the input color method.
+
+#. Use the following APIs to configure the meter object
+
+ * Select the input protocol color with ``rte_mtr_color_in_protocol_set()`` API.
+
+ * If needed, update the input color table at runtime using
+ ``rte_mtr_meter_vlan_table_update()`` and ``rte_mtr_meter_dscp_table_update()``
+ APIs.
+
+ * Application can query the configured input color protocol and its associated
+ priority using ``rte_mtr_color_in_protocol_get()`` and
+ ``rte_mtr_color_in_protocol_priority_get()`` APIs.
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index 88d6e96cc1..74ecc3f53d 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -55,6 +55,13 @@ New Features
Also, make sure to start the actual text at the margin.
=======================================================
+* **Added protocol based input color selection for meter.**
+
+ Added new APIs ``rte_mtr_color_in_protocol_set()``, ``rte_mtr_color_in_protocol_get()``,
+ ``rte_mtr_color_in_protocol_priority_get()``, ``rte_mtr_meter_vlan_table_update()``
+ and updated ``struct rte_mtr_params`` and ``struct rte_mtr_capabilities`` to
+ support protocol based input color selection for meter.
+
* **Updated Intel iavf driver.**
* Added Tx QoS queue rate limitation support.
@@ -112,6 +119,9 @@ ABI Changes
* No ABI change that would break compatibility with 21.11.
+* Experimental structures ``struct rte_mtr_params``
+ and ``struct rte_mtr_capabilities`` updated to support
+ protocol based input color for meter.
Known Issues
------------
diff --git a/lib/ethdev/rte_mtr.c b/lib/ethdev/rte_mtr.c
index e49fcf271c..441ea1dca9 100644
--- a/lib/ethdev/rte_mtr.c
+++ b/lib/ethdev/rte_mtr.c
@@ -207,6 +207,56 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
mtr_id, dscp_table, error);
}
+/** MTR object meter VLAN table update */
+int
+rte_mtr_meter_vlan_table_update(uint16_t port_id,
+ uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ return RTE_MTR_FUNC(port_id, meter_vlan_table_update)(dev,
+ mtr_id, vlan_table, error);
+}
+
+/** Set the input color protocol on MTR object */
+int
+rte_mtr_color_in_protocol_set(uint16_t port_id,
+ uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto,
+ uint32_t priority,
+ struct rte_mtr_error *error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ return RTE_MTR_FUNC(port_id, in_proto_set)(dev,
+ mtr_id, proto, priority, error);
+}
+
+/** Get input color protocols of MTR object */
+int
+rte_mtr_color_in_protocol_get(uint16_t port_id,
+ uint32_t mtr_id,
+ uint64_t *proto_mask,
+ struct rte_mtr_error *error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ return RTE_MTR_FUNC(port_id, in_proto_get)(dev,
+ mtr_id, proto_mask, error);
+}
+
+/** Get input color protocol priority of MTR object */
+int
+rte_mtr_color_in_protocol_priority_get(uint16_t port_id,
+ uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto,
+ uint32_t *priority,
+ struct rte_mtr_error *error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ return RTE_MTR_FUNC(port_id, in_proto_prio_get)(dev,
+ mtr_id, proto, priority, error);
+}
+
/** MTR object enabled stats update */
int
rte_mtr_stats_update(uint16_t port_id,
diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h
index 40df0888c8..008bc84f0d 100644
--- a/lib/ethdev/rte_mtr.h
+++ b/lib/ethdev/rte_mtr.h
@@ -213,6 +213,51 @@ struct rte_mtr_meter_policy_params {
const struct rte_flow_action *actions[RTE_COLORS];
};
+/**
+ * Input color protocol method
+ *
+ * More than one of the method can be enabled for a given meter.
+ * Even if enabled, a method might not be applicable to each input packet,
+ * in case the associated protocol header is not present in the packet.
+ * The highest priority method that is both enabled for the meter and also
+ * applicable for the current input packet wins;
+ * if none is both enabled and applicable, the default input color is used.
+ * @see function rte_mtr_color_in_protocol_set()
+ *
+ */
+enum rte_mtr_color_in_protocol {
+ /**
+ * Enable the detection of the packet input color based on the outermost
+ * VLAN header fields DEI (1 bit) and PCP (3 bits).
+ * These fields are used as index into the VLAN table.
+ *
+ * @see struct rte_mtr_params::vlan_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN = RTE_BIT64(0),
+ /**
+ * Enable the detection of the packet input color based on the innermost
+ * VLAN header fields DEI (1 bit) and PCP (3 bits).
+ * These fields are used as index into the VLAN table.
+ *
+ * @see struct rte_mtr_params::vlan_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_INNER_VLAN = RTE_BIT64(1),
+ /**
+ * Enable the detection of the packet input color based on the outermost
+ * IP DSCP field. These fields are used as index into the DSCP table.
+ *
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_OUTER_IP = RTE_BIT64(2),
+ /**
+ * Enable the detection of the packet input color based on the innermost
+ * IP DSCP field. These fields are used as index into the DSCP table.
+ *
+ * @see struct rte_mtr_params::dscp_table
+ */
+ RTE_MTR_COLOR_IN_PROTO_INNER_IP = RTE_BIT64(3),
+};
+
/**
* Parameters for each traffic metering & policing object
*
@@ -233,20 +278,58 @@ struct rte_mtr_params {
*/
int use_prev_mtr_color;
- /** Meter input color. When non-NULL: it points to a pre-allocated and
+ /** Meter input color based on IP DSCP protocol field.
+ *
+ * Valid when *input_color_proto_mask* set to any of the following
+ * RTE_MTR_COLOR_IN_PROTO_OUTER_IP,
+ * RTE_MTR_COLOR_IN_PROTO_INNER_IP
+ *
+ * When non-NULL: it points to a pre-allocated and
* pre-populated table with exactly 64 elements providing the input
* color for each value of the IPv4/IPv6 Differentiated Services Code
- * Point (DSCP) input packet field. When NULL: it is equivalent to
- * setting this parameter to an all-green populated table (i.e. table
- * with all the 64 elements set to green color). The color blind mode
- * is configured by setting *use_prev_mtr_color* to 0 and *dscp_table*
- * to either NULL or to an all-green populated table. When
- * *use_prev_mtr_color* is non-zero value or when *dscp_table* contains
- * at least one yellow or red color element, then the color aware mode
- * is configured.
+ * Point (DSCP) input packet field.
+ *
+ * When NULL: it is equivalent to setting this parameter to an all-green
+ * populated table (i.e. table with all the 64 elements set to green
+ * color). The color blind mode is configured by setting
+ * *use_prev_mtr_color* to 0 and *dscp_table* to either NULL or to an
+ * all-green populated table.
+ *
+ * When *use_prev_mtr_color* is non-zero value or when *dscp_table*
+ * contains at least one yellow or red color element, then the color
+ * aware mode is configured.
+ *
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_IP
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_IP
+ * @see struct rte_mtr_params::input_color_proto_mask
*/
enum rte_color *dscp_table;
-
+ /** Meter input color based on VLAN DEI(1bit), PCP(3 bits) protocol
+ * fields.
+ *
+ * Valid when *input_color_proto_mask* set to any of the following
+ * RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN,
+ * RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
+ *
+ * When non-NULL: it points to a pre-allocated and pre-populated
+ * table with exactly 16 elements providing the input color for
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ *
+ * When NULL: it is equivalent to setting this parameter to an
+ * all-green populated table (i.e. table with
+ * all the 16 elements set to green color). The color blind mode
+ * is configured by setting *use_prev_mtr_color* to 0 and
+ * *vlan_table* to either NULL or to an all-green populated table.
+ *
+ * When *use_prev_mtr_color* is non-zero value
+ * or when *vlan_table* contains at least one yellow or
+ * red color element, then the color aware mode is configured.
+ *
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN
+ * @see enum rte_mtr_color_in_protocol::RTE_MTR_COLOR_IN_PROTO_INNER_VLAN
+ * @see struct rte_mtr_params::input_color_proto_mask
+ */
+ enum rte_color *vlan_table;
/** Non-zero to enable the meter, zero to disable the meter at the time
* of MTR object creation. Ignored when the meter profile indicated by
* *meter_profile_id* is set to NONE.
@@ -261,6 +344,12 @@ struct rte_mtr_params {
/** Meter policy ID. @see rte_mtr_meter_policy_add() */
uint32_t meter_policy_id;
+
+ /** Input color to be set for the input packet when none of the
+ * enabled input color methods is applicable to the input packet.
+ * Ignored when this when *input_color_proto_mask* set to zero.
+ */
+ enum rte_color default_input_color;
};
/**
@@ -417,6 +506,16 @@ struct rte_mtr_capabilities {
* @see enum rte_mtr_stats_type
*/
uint64_t stats_mask;
+
+ /** Set of supported input color protocol.
+ * @see enum rte_mtr_color_in_protocol
+ */
+ uint64_t input_color_proto_mask;
+
+ /** When non-zero, it indicates that driver supports separate
+ * input color table for given ethdev port.
+ */
+ int separate_input_color_table_per_port;
};
/**
@@ -832,6 +931,103 @@ rte_mtr_meter_dscp_table_update(uint16_t port_id,
enum rte_color *dscp_table,
struct rte_mtr_error *error);
+/**
+ * MTR object VLAN table update
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[in] vlan_table
+ * When non-NULL: it points to a pre-allocated and pre-populated table with
+ * exactly 16 elements providing the input color for each value of the
+ * each value of the DEI(1bit), PCP(3 bits) input packet field.
+ * When NULL: it is equivalent to setting this parameter to an "all-green"
+ * populated table (i.e. table with all the 16 elements set to green color).
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+__rte_experimental
+int
+rte_mtr_meter_vlan_table_update(uint16_t port_id, uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error);
+
+/**
+ * Set the input color protocol for a given MTR object
+ *
+ * More than one of the method can be enabled for a given meter.
+ * Even if enabled, a method might not be applicable to each input packet,
+ * in case the associated protocol header is not present in the packet.
+ * The highest priority method that is both enabled for the meter and also
+ * applicable for the current input packet wins;
+ * if none is both enabled and applicable, the default input color is used.
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[in] proto
+ * Input color protocol.
+ * @param[in] priority
+ * Input color protocol priority. Value zero indicates
+ * the highest priority.
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+__rte_experimental
+int
+rte_mtr_color_in_protocol_set(uint16_t port_id, uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto, uint32_t priority,
+ struct rte_mtr_error *error);
+
+/**
+ * Get the input color protocol for a given MTR object
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[out] proto_mask
+ * Selected input color protocols as bit mask.
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ *
+ */
+__rte_experimental
+int
+rte_mtr_color_in_protocol_get(uint16_t port_id, uint32_t mtr_id,
+ uint64_t *proto_mask,
+ struct rte_mtr_error *error);
+
+/**
+ * Get the priority associated with input color protocol for a given MTR object
+ *
+ * @param[in] port_id
+ * The port identifier of the Ethernet device.
+ * @param[in] mtr_id
+ * MTR object ID. Needs to be valid.
+ * @param[in] proto
+ * Input color protocol.
+ * @param[out] priority
+ * Input color protocol priority associated with proto.
+ * @param[out] error
+ * Error details. Filled in only on error, when not NULL.
+ * @return
+ * 0 on success, non-zero error code otherwise.
+ */
+__rte_experimental
+int
+rte_mtr_color_in_protocol_priority_get(uint16_t port_id, uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto, uint32_t *priority,
+ struct rte_mtr_error *error);
+
/**
* MTR object enabled statistics counters update
*
diff --git a/lib/ethdev/rte_mtr_driver.h b/lib/ethdev/rte_mtr_driver.h
index ee8c6ef7ad..f7dca9a54c 100644
--- a/lib/ethdev/rte_mtr_driver.h
+++ b/lib/ethdev/rte_mtr_driver.h
@@ -97,6 +97,32 @@ typedef int (*rte_mtr_meter_dscp_table_update_t)(struct rte_eth_dev *dev,
enum rte_color *dscp_table,
struct rte_mtr_error *error);
+/** @internal mtr object meter vlan table update. */
+typedef int (*rte_mtr_meter_vlan_table_update_t)(struct rte_eth_dev *dev,
+ uint32_t mtr_id,
+ enum rte_color *vlan_table,
+ struct rte_mtr_error *error);
+
+/** @internal Set the input color protocol on MTR object. */
+typedef int (*rte_mtr_meter_color_in_proto_set_t)(struct rte_eth_dev *dev,
+ uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto,
+ uint32_t priority,
+ struct rte_mtr_error *error);
+
+/** @internal Get the input color protocols of MTR object. */
+typedef int (*rte_mtr_meter_color_in_proto_get_t)(struct rte_eth_dev *dev,
+ uint32_t mtr_id,
+ uint64_t *proto_mask,
+ struct rte_mtr_error *error);
+
+/** @internal Get the input color protocol priority of MTR object. */
+typedef int (*rte_mtr_meter_color_in_proto_prio_get_t)(struct rte_eth_dev *dev,
+ uint32_t mtr_id,
+ enum rte_mtr_color_in_protocol proto,
+ uint32_t *priority,
+ struct rte_mtr_error *error);
+
/** @internal MTR object enabled stats update. */
typedef int (*rte_mtr_stats_update_t)(struct rte_eth_dev *dev,
uint32_t mtr_id,
@@ -139,6 +165,18 @@ struct rte_mtr_ops {
/** MTR object meter DSCP table update */
rte_mtr_meter_dscp_table_update_t meter_dscp_table_update;
+ /** MTR object meter VLAN table update */
+ rte_mtr_meter_vlan_table_update_t meter_vlan_table_update;
+
+ /** Set the input color protocol on MTR object. */
+ rte_mtr_meter_color_in_proto_set_t in_proto_set;
+
+ /** Get the input color protocol of MTR object. */
+ rte_mtr_meter_color_in_proto_get_t in_proto_get;
+
+ /** Get the input color protocol priority of MTR object. */
+ rte_mtr_meter_color_in_proto_prio_get_t in_proto_prio_get;
+
/** MTR object enabled stats update */
rte_mtr_stats_update_t stats_update;
diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
index 20391ab29e..daca7851f2 100644
--- a/lib/ethdev/version.map
+++ b/lib/ethdev/version.map
@@ -279,6 +279,12 @@ EXPERIMENTAL {
rte_flow_async_action_handle_create;
rte_flow_async_action_handle_destroy;
rte_flow_async_action_handle_update;
+
+ # added in 22.07
+ rte_mtr_color_in_protocol_get;
+ rte_mtr_color_in_protocol_priority_get;
+ rte_mtr_color_in_protocol_set;
+ rte_mtr_meter_vlan_table_update;
};
INTERNAL {
--
2.36.0
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [dpdk-dev] [PATCH v5] ethdev: mtr: support protocol based input color selection
2022-05-01 14:46 ` [dpdk-dev] [PATCH v5] " jerinj
@ 2022-05-04 8:52 ` Ray Kinsella
2022-05-05 10:56 ` Dumitrescu, Cristian
2022-05-12 7:36 ` Andrew Rybchenko
2 siblings, 0 replies; 30+ messages in thread
From: Ray Kinsella @ 2022-05-04 8:52 UTC (permalink / raw)
To: jerinj
Cc: dev, Cristian Dumitrescu, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko, ajit.khaparde, aboyer, beilei.xing,
bruce.richardson, chas3, chenbo.xia, ciara.loftus, dsinghrawat,
ed.czeck, evgenys, grive, g.singh, zhouguoyang, haiyue.wang,
hkalra, heinrich.kuhn, hemant.agrawal, hyonkim, igorch,
irusskikh, jgrajcia, jasvinder.singh, jianwang, jiawenwu,
jingjing.wu, johndale, john.miller, linville, keith.wiles,
kirankumark, oulijun, lironh, longli, mw, spinler, matan,
matt.peters, maxime.coquelin, mk, humin29, pnalla, ndabilpuram,
qiming.yang, qi.z.zhang, radhac, rahul.lakkireddy, rmody,
rosen.xu, sachin.saxena, skoteshwar, shshaikh, shaibran,
shepard.siegel, asomalap, somnath.kotur, sthemmin,
steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2
jerinj@marvell.com writes:
> From: Jerin Jacob <jerinj@marvell.com>
>
> Currently, meter object supports only DSCP based on input color table,
> The patch enhance that to support VLAN based input color table,
> color table based on inner field for the tunnel use case, and
> support for fallback color per meter if packet based on a different field.
>
> All of the above features are exposed through capability and added
> additional capability to specify the implementation supports
> more than one input color table per ethdev port.
>
> Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> ---
>
> v5..v4:
>
> - Improved the Doxgen comments as per
> http://patches.dpdk.org/project/dpdk/patch/20220421180241.514767-1-jerinj@marvell.com/
> - Removed input_color_proto_mask
> - Renamed rte_mtr_color_in_protocol_priority_set() to rte_mtr_color_in_protocol_set()
> - Introduced rte_mtr_color_in_protocol_get(), rte_mtr_color_in_protocol_priority_get()
> for getting the configured input color protocol.
>
> v4..v3:
>
> - Aligned with community meeting call which is documented in
> https://patches.dpdk.org/project/dpdk/patch/20220301085824.1041009-1-skori@marvell.com/
> as last message. With following exception,
> - Used RTE_MTR_COLOR_IN_*_DSCP instead of RTE_MTR_COLOR_IN_*_IP as
> there is already dscp_table and rte_mtr_meter_dscp_table_update() API.
> Changing above symbols break existing application for no good.
> - Updated 22.07 release notes
> - Remove testpmd changes from series to finalize the API spec first and
> then we can send testpmd changes.
>
> v3..v2:
>
> - Fix input color flags as a bitmask
> - Add definitions for newly added API
>
> v2..v1:
> - Fix seperate typo
>
> v1..RFC:
>
> Address the review comments by Cristian at
> https://patches.dpdk.org/project/dpdk/patch/20210820082401.3778736-1-jerinj@marvell.com/
>
> .../traffic_metering_and_policing.rst | 35 +++
> doc/guides/rel_notes/release_22_07.rst | 10 +
> lib/ethdev/rte_mtr.c | 50 ++++
> lib/ethdev/rte_mtr.h | 216 +++++++++++++++++-
> lib/ethdev/rte_mtr_driver.h | 38 +++
> lib/ethdev/version.map | 6 +
> 6 files changed, 345 insertions(+), 10 deletions(-)
>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [dpdk-dev] [PATCH v5] ethdev: mtr: support protocol based input color selection
2022-05-01 14:46 ` [dpdk-dev] [PATCH v5] " jerinj
2022-05-04 8:52 ` Ray Kinsella
@ 2022-05-05 10:56 ` Dumitrescu, Cristian
2022-05-12 7:36 ` Andrew Rybchenko
2 siblings, 0 replies; 30+ messages in thread
From: Dumitrescu, Cristian @ 2022-05-05 10:56 UTC (permalink / raw)
To: jerinj, dev, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko,
Ray Kinsella
Cc: ajit.khaparde, aboyer, Xing, Beilei, Richardson, Bruce, chas3,
Xia, Chenbo, Loftus, Ciara, dsinghrawat, ed.czeck, evgenys,
grive, g.singh, zhouguoyang, Wang, Haiyue, hkalra, heinrich.kuhn,
hemant.agrawal, hyonkim, igorch, irusskikh, jgrajcia, Singh,
Jasvinder, jianwang, jiawenwu, Wu, Jingjing, Daley, John,
john.miller, linville, Wiles, Keith, kirankumark, oulijun,
lironh, longli, mw, spinler, matan, Peters, Matt,
maxime.coquelin, mk, humin29, pnalla, ndabilpuram, Yang, Qiming,
Zhang, Qi Z, radhac, rahul.lakkireddy, rmody, Xu, Rosen,
sachin.saxena, skoteshwar, shshaikh, shaibran, Shepard Siegel,
asomalap, somnath.kotur, sthemmin, Webster, Steven, skori,
mtetsuyah, vburru, viacheslavo, Wang, Xiao W, cloud.wangxiaoyun,
yisen.zhuang, Wang, Yong, xuanziyang2
> -----Original Message-----
> From: jerinj@marvell.com <jerinj@marvell.com>
> Sent: Sunday, May 1, 2022 3:47 PM
> To: dev@dpdk.org; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> Thomas Monjalon <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@xilinx.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; Ray Kinsella <mdr@ashroe.eu>
> Cc: ajit.khaparde@broadcom.com; aboyer@pensando.io; Xing, Beilei
> <beilei.xing@intel.com>; Richardson, Bruce <bruce.richardson@intel.com>;
> chas3@att.com; Xia, Chenbo <chenbo.xia@intel.com>; Loftus, Ciara
> <ciara.loftus@intel.com>; dsinghrawat@marvell.com;
> ed.czeck@atomicrules.com; evgenys@amazon.com; grive@u256.net;
> g.singh@nxp.com; zhouguoyang@huawei.com; Wang, Haiyue
> <haiyue.wang@intel.com>; hkalra@marvell.com; heinrich.kuhn@corigine.com;
> hemant.agrawal@nxp.com; hyonkim@cisco.com; igorch@amazon.com;
> irusskikh@marvell.com; jgrajcia@cisco.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>; jianwang@trustnetic.com;
> jiawenwu@trustnetic.com; Wu, Jingjing <jingjing.wu@intel.com>; Daley, John
> <johndale@cisco.com>; john.miller@atomicrules.com; linville@tuxdriver.com;
> Wiles, Keith <keith.wiles@intel.com>; kirankumark@marvell.com;
> oulijun@huawei.com; lironh@marvell.com; longli@microsoft.com;
> mw@semihalf.com; spinler@cesnet.cz; matan@nvidia.com; Peters, Matt
> <matt.peters@windriver.com>; maxime.coquelin@redhat.com;
> mk@semihalf.com; humin29@huawei.com; pnalla@marvell.com;
> ndabilpuram@marvell.com; Yang, Qiming <qiming.yang@intel.com>; Zhang,
> Qi Z <qi.z.zhang@intel.com>; radhac@marvell.com;
> rahul.lakkireddy@chelsio.com; rmody@marvell.com; Xu, Rosen
> <rosen.xu@intel.com>; sachin.saxena@oss.nxp.com; skoteshwar@marvell.com;
> shshaikh@marvell.com; shaibran@amazon.com; Shepard Siegel
> <shepard.siegel@atomicrules.com>; asomalap@amd.com;
> somnath.kotur@broadcom.com; sthemmin@microsoft.com; Webster, Steven
> <steven.webster@windriver.com>; skori@marvell.com;
> mtetsuyah@gmail.com; vburru@marvell.com; viacheslavo@nvidia.com; Wang,
> Xiao W <xiao.w.wang@intel.com>; cloud.wangxiaoyun@huawei.com;
> yisen.zhuang@huawei.com; Wang, Yong <yongwang@vmware.com>;
> xuanziyang2@huawei.com; Jerin Jacob <jerinj@marvell.com>
> Subject: [dpdk-dev] [PATCH v5] ethdev: mtr: support protocol based input color
> selection
>
> From: Jerin Jacob <jerinj@marvell.com>
>
> Currently, meter object supports only DSCP based on input color table,
> The patch enhance that to support VLAN based input color table,
> color table based on inner field for the tunnel use case, and
> support for fallback color per meter if packet based on a different field.
>
> All of the above features are exposed through capability and added
> additional capability to specify the implementation supports
> more than one input color table per ethdev port.
>
> Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> ---
>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Thanks very much, Jerin!
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [dpdk-dev] [PATCH v5] ethdev: mtr: support protocol based input color selection
2022-05-01 14:46 ` [dpdk-dev] [PATCH v5] " jerinj
2022-05-04 8:52 ` Ray Kinsella
2022-05-05 10:56 ` Dumitrescu, Cristian
@ 2022-05-12 7:36 ` Andrew Rybchenko
2022-05-12 11:03 ` Jerin Jacob
2 siblings, 1 reply; 30+ messages in thread
From: Andrew Rybchenko @ 2022-05-12 7:36 UTC (permalink / raw)
To: jerinj, dev, Cristian Dumitrescu, Thomas Monjalon, Ray Kinsella,
Ferruh Yigit
Cc: ajit.khaparde, aboyer, beilei.xing, bruce.richardson, chas3,
chenbo.xia, ciara.loftus, dsinghrawat, ed.czeck, evgenys, grive,
g.singh, zhouguoyang, haiyue.wang, hkalra, heinrich.kuhn,
hemant.agrawal, hyonkim, igorch, irusskikh, jgrajcia,
jasvinder.singh, jianwang, jiawenwu, jingjing.wu, johndale,
john.miller, linville, keith.wiles, kirankumark, oulijun, lironh,
longli, mw, spinler, matan, matt.peters, maxime.coquelin, mk,
humin29, pnalla, ndabilpuram, qiming.yang, qi.z.zhang, radhac,
rahul.lakkireddy, rmody, rosen.xu, sachin.saxena, skoteshwar,
shshaikh, shaibran, shepard.siegel, asomalap, somnath.kotur,
sthemmin, steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2
Hi Jerin,
On 5/1/22 17:46, jerinj@marvell.com wrote:
> From: Jerin Jacob <jerinj@marvell.com>
>
> Currently, meter object supports only DSCP based on input color table,
> The patch enhance that to support VLAN based input color table,
> color table based on inner field for the tunnel use case, and
> support for fallback color per meter if packet based on a different field.
>
> All of the above features are exposed through capability and added
> additional capability to specify the implementation supports
> more than one input color table per ethdev port.
>
> Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
the patch LGTM, but I have a couple of questions to clarify:
1. Will we have API usage patches in the release cycle (I guess
testpmd)?
2. Will we have net driver patches which add support for
new driver callbacks and advertise added capabilities?
Thanks,
Andrew.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [dpdk-dev] [PATCH v5] ethdev: mtr: support protocol based input color selection
2022-05-12 7:36 ` Andrew Rybchenko
@ 2022-05-12 11:03 ` Jerin Jacob
2022-05-19 7:05 ` Andrew Rybchenko
0 siblings, 1 reply; 30+ messages in thread
From: Jerin Jacob @ 2022-05-12 11:03 UTC (permalink / raw)
To: Andrew Rybchenko
Cc: Jerin Jacob, dpdk-dev, Cristian Dumitrescu, Thomas Monjalon,
Ray Kinsella, Ferruh Yigit, Ajit Khaparde, Andrew Boyer,
Beilei Xing, Richardson, Bruce, Chas Williams, Xia, Chenbo,
Ciara Loftus, Devendra Singh Rawat, Ed Czeck, Evgeny Schemeilin,
Gaetan Rivet, Gagandeep Singh, Guoyang Zhou, Haiyue Wang,
Harman Kalra, heinrich.kuhn, Hemant Agrawal, Hyong Youb Kim,
Igor Chauskin, Igor Russkikh, Jakub Grajciar, Jasvinder Singh,
Jian Wang, Jiawen Wu, Jingjing Wu, John Daley, John Miller,
John W. Linville, Wiles, Keith, Kiran Kumar K, Lijun Ou,
Liron Himi, Long Li, Marcin Wojtas, Martin Spinler, Matan Azrad,
Matt Peters, Maxime Coquelin, Michal Krawczyk, Min Hu (Connor,
Pradeep Kumar Nalla, Nithin Dabilpuram, Qiming Yang, Qi Zhang,
Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
Rosen Xu, Sachin Saxena, Satha Koteswara Rao Kottidi,
Shahed Shaikh, Shai Brandes, Shepard Siegel,
Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
Veerasenareddy Burru, Viacheslav Ovsiienko, Xiao Wang,
Xiaoyun Wang, Yisen Zhuang, Yong Wang, Ziyang Xuan
On Thu, May 12, 2022 at 1:06 PM Andrew Rybchenko
<andrew.rybchenko@oktetlabs.ru> wrote:
>
> Hi Jerin,
Hi Andrew,
>
> On 5/1/22 17:46, jerinj@marvell.com wrote:
> > From: Jerin Jacob <jerinj@marvell.com>
> >
> > Currently, meter object supports only DSCP based on input color table,
> > The patch enhance that to support VLAN based input color table,
> > color table based on inner field for the tunnel use case, and
> > support for fallback color per meter if packet based on a different field.
> >
> > All of the above features are exposed through capability and added
> > additional capability to specify the implementation supports
> > more than one input color table per ethdev port.
> >
> > Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> > Signed-off-by: Jerin Jacob <jerinj@marvell.com>
>
> the patch LGTM, but I have a couple of questions to clarify:
>
> 1. Will we have API usage patches in the release cycle (I guess
> testpmd)?
>
> 2. Will we have net driver patches which add support for
> new driver callbacks and advertise added capabilities?
Yes. Both will be there for this release. Most likely post rc1.
We have testpmd, cnxk driver changes for the v1 version of the
spec[1]. We will update both for the latest spec version.(We just
awaiting for spec to merge)
[1]
https://patches.dpdk.org/project/dpdk/patch/20220301090056.1042866-3-skori@marvell.com/
https://patches.dpdk.org/project/dpdk/patch/20220301090056.1042866-2-skori@marvell.com/
>
> Thanks,
> Andrew.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [dpdk-dev] [PATCH v5] ethdev: mtr: support protocol based input color selection
2022-05-12 11:03 ` Jerin Jacob
@ 2022-05-19 7:05 ` Andrew Rybchenko
0 siblings, 0 replies; 30+ messages in thread
From: Andrew Rybchenko @ 2022-05-19 7:05 UTC (permalink / raw)
To: Jerin Jacob
Cc: Jerin Jacob, dpdk-dev, Cristian Dumitrescu, Thomas Monjalon,
Ray Kinsella, Ferruh Yigit, Ajit Khaparde, Andrew Boyer,
Beilei Xing, Richardson, Bruce, Chas Williams, Xia, Chenbo,
Ciara Loftus, Devendra Singh Rawat, Ed Czeck, Evgeny Schemeilin,
Gaetan Rivet, Gagandeep Singh, Guoyang Zhou, Haiyue Wang,
Harman Kalra, heinrich.kuhn, Hemant Agrawal, Hyong Youb Kim,
Igor Chauskin, Igor Russkikh, Jakub Grajciar, Jasvinder Singh,
Jian Wang, Jiawen Wu, Jingjing Wu, John Daley, John Miller,
John W. Linville, Wiles, Keith, Kiran Kumar K, Lijun Ou,
Liron Himi, Long Li, Marcin Wojtas, Martin Spinler, Matan Azrad,
Matt Peters, Maxime Coquelin, Michal Krawczyk, Min Hu (Connor,
Pradeep Kumar Nalla, Nithin Dabilpuram, Qiming Yang, Qi Zhang,
Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
Rosen Xu, Sachin Saxena, Satha Koteswara Rao Kottidi,
Shahed Shaikh, Shai Brandes, Shepard Siegel,
Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
Veerasenareddy Burru, Viacheslav Ovsiienko, Xiao Wang,
Xiaoyun Wang, Yisen Zhuang, Yong Wang, Ziyang Xuan
On 5/12/22 14:03, Jerin Jacob wrote:
> On Thu, May 12, 2022 at 1:06 PM Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru> wrote:
>>
>> Hi Jerin,
>
> Hi Andrew,
>
>>
>> On 5/1/22 17:46, jerinj@marvell.com wrote:
>>> From: Jerin Jacob <jerinj@marvell.com>
>>>
>>> Currently, meter object supports only DSCP based on input color table,
>>> The patch enhance that to support VLAN based input color table,
>>> color table based on inner field for the tunnel use case, and
>>> support for fallback color per meter if packet based on a different field.
>>>
>>> All of the above features are exposed through capability and added
>>> additional capability to specify the implementation supports
>>> more than one input color table per ethdev port.
>>>
>>> Suggested-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
>>> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
>>
>> the patch LGTM, but I have a couple of questions to clarify:
>>
>> 1. Will we have API usage patches in the release cycle (I guess
>> testpmd)?
>>
>> 2. Will we have net driver patches which add support for
>> new driver callbacks and advertise added capabilities?
>
> Yes. Both will be there for this release. Most likely post rc1.
>
> We have testpmd, cnxk driver changes for the v1 version of the
> spec[1]. We will update both for the latest spec version.(We just
> awaiting for spec to merge)
>
> [1]
> https://patches.dpdk.org/project/dpdk/patch/20220301090056.1042866-3-skori@marvell.com/
> https://patches.dpdk.org/project/dpdk/patch/20220301090056.1042866-2-skori@marvell.com/
>
>>
>> Thanks,
>> Andrew.
Applied, thanks.
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2022-05-19 7:05 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-20 8:24 [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features jerinj
2021-08-30 9:23 ` Jerin Jacob
2021-09-27 16:20 ` Ferruh Yigit
2021-10-11 15:14 ` Dumitrescu, Cristian
2021-11-17 12:00 ` Jerin Jacob
2021-12-07 9:55 ` Jerin Jacob
2021-12-07 18:00 ` Dumitrescu, Cristian
2022-01-10 9:35 ` Jerin Jacob
2022-02-14 11:56 ` [dpdk-dev] [v22.07] [PATCH] ethdev: mtr: support input color selection jerinj
2022-02-14 12:02 ` [dpdk-dev] [v22.07] [PATCH v2] " jerinj
2022-03-01 8:58 ` [PATCH v3 1/1] " skori
2022-03-01 10:49 ` [EXT] " Sunil Kumar Kori
2022-03-01 17:48 ` Dumitrescu, Cristian
2022-04-05 21:14 ` Dumitrescu, Cristian
2022-04-07 10:51 ` Jerin Jacob
2022-04-07 13:25 ` Dumitrescu, Cristian
2022-04-07 14:39 ` Jerin Jacob
2022-04-11 14:45 ` Dumitrescu, Cristian
2022-04-12 6:48 ` Ori Kam
2022-04-21 18:02 ` [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based " jerinj
2022-04-26 10:19 ` Ray Kinsella
2022-05-01 12:52 ` Jerin Jacob
2022-04-26 12:08 ` Dumitrescu, Cristian
2022-05-01 12:56 ` Jerin Jacob
2022-05-01 14:46 ` [dpdk-dev] [PATCH v5] " jerinj
2022-05-04 8:52 ` Ray Kinsella
2022-05-05 10:56 ` Dumitrescu, Cristian
2022-05-12 7:36 ` Andrew Rybchenko
2022-05-12 11:03 ` Jerin Jacob
2022-05-19 7:05 ` Andrew Rybchenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).