Hi Cristian,
> -----Original Message-----
> From: Cristian Dumitrescu <cristian.dumitre...@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.dumitre...@intel.com>
> Signed-off-by: Qi Zhang <qi.z.zh...@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
