Hi Andrey,
PSB
> -----Original Message-----
> From: Andrey Vesnovaty <andr...@nvidia.com>
> Sent: Wednesday, September 9, 2020 11:30 PM
>
> Attach SFT flow context to packet with SFT action.
> Match on SFT flow context (attached to packet),
> with SFT item.
>
> Signed-off-by: Andrey Vesnovaty <andr...@nvidia.com>
> ---
> lib/librte_ethdev/rte_flow.h | 84 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 84 insertions(+)
>
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index da8bfa5489..24390e6ab4 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -537,6 +537,12 @@ enum rte_flow_item_type {
> */
> RTE_FLOW_ITEM_TYPE_ECPRI,
>
> + /**
You are missing the Meta, tag not relevant for RFC but please notice for the
patch.
> + * Matches SFT context (see fields of struct rte_flow_item_sft).
> + *
> + * See struct rte_flow_item_sft.
> + */
> + RTE_FLOW_ITEM_TYPE_SFT,
> };
>
> /**
> @@ -1579,6 +1585,54 @@ static const struct rte_flow_item_ecpri
> rte_flow_item_ecpri_mask = {
> };
> #endif
>
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * RTE_FLOW_ITEM_TYPE_SFT
> + *
> + * Matches context of flow in SFT table.
> + *
> + * 5-tuple: src/dest IP + src/dest port + IP protocol.
> + * zone: application defined value cupled with 5-tuple to identify flow,
> + * example - VxLAN, VLAN.
> + * SFT: Statfull flow table
> + * SFT in scope of ethernet device (port) is HW offloaded lookup table
> + * where key is zone + 5-tuple & value is statefull flow context.
> + * Contents of the SFT maintained by SFT PMD (see SFT PMD API in rte_sft).
> + *
> + * The structure describes SFT flow context.
> + * All the fields of the structure, except @p fid, should be considered as
> + * user defined.
> + * The @p fid assigned by RTE SFT & used as unique flow identifier.
> + * SFT context attached to packet by action ``SFT`` (see
> RTE_FLOW_ACTION_SFT).
> + *
> + * SFT default context defined as context attached to packet when there is no
> + * entry for the flow in SFT. The @p state has application reserved value
> + * meaning that SFT context for the packet undefined since entry wasn't found
> + * in SFT. If state 'undefined' then @p zone should be valid othervice @p fid
> + * should be valid.
> + *
> + * Context considered virtual since the method of storing this info on packet
> + * is PMD/implementation specific & may involve mapping methods if there is
> + * 'not enough bits' to store entire contents of struct rte_flow_item_sft.
> + *
> + * Maximal value/size of each field depends on HW capabilities and
> considered
> + * as implementation specific.
> + */
> +struct rte_flow_item_sft {
> + union {
> + uint32_t fid; /**< SFT flow identifier. */
> + uint32_t zone; /**< Zone assigned to flow. */
> + };
> + uint8_t state; /**< User defined flow state. */
> + uint8_t fid_valid:1; /**< fid field validity bit. */
> + uint8_t zone_valid:1; /**< zone fieald validity bit. */
> + uint8_t state_valid:1; /**< state fieald validity bit. */
> + uint8_t user_data_size; /**< user_data buffer size. */
> + uint8_t *user_data; /**< Arbitrary user data. */
> +};
> +
This object is only used to match and not set so
why do we need the union? I understand that later when reporting to the SFT in
the application layer
sometimes you will get zone while other time you will get fid.
>From rte flow you are matching on given object which is 32 bit.
What are the matchable fields? (fid / zone / user_data / fid_valid ... )
Do you think that some of the times the match will be on he fid other on the
zone?
If so they should not be union.
I think zone is the responsibility of the application to save and to match. So
I don't see why it is
needed here.
> /**
> * Matching pattern item definition.
> *
> @@ -2132,6 +2186,15 @@ enum rte_flow_action_type {
> * see enum RTE_ETH_EVENT_FLOW_AGED
> */
> RTE_FLOW_ACTION_TYPE_AGE,
> +
> + /**
> + * RTE_FLOW_ACTION_TYPE_SFT
> + *
> + * Set SFT context and redirect to continue processing.
> + *
> + * See struct rte_flow_action_sft.
> + */
> + RTE_FLOW_ACTION_TYPE_SFT,
> };
>
> /**
> @@ -2721,6 +2784,27 @@ rte_flow_dynf_metadata_set(struct rte_mbuf *m,
> uint32_t v)
> *RTE_FLOW_DYNF_METADATA(m) = v;
> }
>
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * RTE_FLOW_ACTION_TYPE_SFT
> + *
> + * Attaches an SFT context (see struct rte_flow_item_sft) to packet.
> + *
> + * Performs lookup by *zone* and 5-tuple in SFT; if entry found the related
> SFT
> + * context will be attached othervise default SFT context attached (see
> + * 'SFT default context' in struct rte_flow_item_sft description).
> + * Adding action of type ``SFT`` to the list of rule actions may impose
> + * limitations on other rule actions added to the list, depending on specific
> + * PMD implementation.
> + *
> + * For 5-tuple, zone & SFT definitions see `struct rte_flow_item_sft`.
> + */
> +struct rte_flow_action_sft {
> + uint32_t zone; /**< Zone for lookup in SFT */
> +};
> +
> /*
> * Definition of a single action.
> *
> --
> 2.26.2
Thanks,
Ori
