[PATCH] ethdev: add flow API support for P4-programmable devices

[Ori Kam]

Hi Cristian,

> -----Original Message-----
> From: Cristian Dumitrescu <cristian.dumitrescu at intel.com>
> Sent: Friday, September 15, 2023 10:00 PM
> Subject: [PATCH] ethdev: add flow API support for P4-programmable devices
> 
> This patch introduces the new "program" action type to enable flow API
> support for P4-programmable devices.
> 
> In the case of P4-programmable devices, the device is initially blank.
> The flow items and actions are defined by the user (outside of any
> vendor control) through the P4 program, which is typically compiled
> into firmware that is loaded on the device at init time. These flow
> items and actions are then used during the run-time phase to add flows
> on the device.
> 
> Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu at intel.com>
> Signed-off-by: Qi Zhang <qi.z.zhang at intel.com>
> ---
> Change log:
> 
> V1:
> -Incorporated the feedback from the DPDK Summit 2023, sincere thanks
> to the many colleagues who contributed!
> -Based on Ori's suggestion, decided to reuse the existing "flex" flow
> item instead of defining a new flow item, so only the new "program"
> action type is required.
> 
> RFC:
> -RFC link: https://mails.dpdk.org/archives/dev/2023-August/273703.html
> 
>  lib/ethdev/rte_flow.h | 50 +++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
> 
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index 2ebb76dbc0..9eef5027d0 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -2981,6 +2981,15 @@ enum rte_flow_action_type {
>  	 * @see struct rte_flow_action_indirect_list
>  	 */
>  	RTE_FLOW_ACTION_TYPE_INDIRECT_LIST,
> +
> +	/**
> +	 * Program action. These actions are defined by the program currently
> +	 * loaded on the device. For example, these actions are applicable to
> +	 * devices that can be programmed through the P4 language.
> +	 *
> +	 * @see struct rte_flow_action_prog.
> +	 */
> +	RTE_FLOW_ACTION_TYPE_PROG,
>  };
> 
>  /**
> @@ -4055,6 +4064,47 @@ struct rte_flow_indirect_update_flow_meter_mark
> {
>  	enum rte_color init_color;
>  };
> 
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice.
> + *
> + * Program action argument configuration parameters.
> + *
> + * The action argument field length must be non-zero. The action argument
> field

Why can't it be zero? I can see actions that don't have any arguments.

> + * value must be non-NULL, with the value bytes specified in network byte
> order.
> + *
> + * @see struct rte_flow_action_prog
> + */
> +struct rte_flow_action_prog_argument {
> +	/** Argument name. */
> +	const char *arg_name;

Maybe uint32 id?

> +	/** Argument field length. */
> +	uint32_t arg_length;

size?

> +	/** Argument field value. */
> +	const uint8_t *arg_value;

data?

I just wish to make it align with other names we have in rte_flow
for example raw_encap
In any case I think we can drop the arg prefix.

> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice.
> + *
> + * RTE_FLOW_ACTION_TYPE_PROG
> + *
> + * Program action configuration parameters.
> + *
> + * Each action can have zero or more arguments.
> + *
> + * @see RTE_FLOW_ACTION_TYPE_PROG
> + */
> +struct rte_flow_action_prog {
> +	/** Action name. */
> +	const char *action_name;
> +	/** Number of action arguments. */
> +	uint32_t action_args_num;
> +	/** Action arguments array. */
> +	const struct rte_flow_action_prog_argument *action_args;
> +};
> +
>  /* Mbuf dynamic field offset for metadata. */
>  extern int32_t rte_flow_dynf_metadata_offs;
> 
> --
> 2.34.1

Best,
Ori