Re: [RFC 1/3] ethdev: support GRE optional fields

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 12/30/2021 3:08 AM, Sean Zhang wrote:
> Add flow pattern items and header format for matching optional fields
> (checksum/key/sequence) in GRE header. And the flags in gre item should
> be correspondingly set with the new added items.
> 
> Signed-off-by: Sean Zhang <xiazhang@nvidia.com>
> ---
>   doc/guides/prog_guide/rte_flow.rst | 16 ++++++++++++++++
>   lib/ethdev/rte_flow.c              |  1 +
>   lib/ethdev/rte_flow.h              | 18 ++++++++++++++++++
>   3 files changed, 35 insertions(+)
> 
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index c51ed88..48d5685 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1113,6 +1113,22 @@ This should be preceded by item ``GRE``.
>   - Value to be matched is a big-endian 32 bit integer.
>   - When this item present it implicitly match K bit in default mask as "1"
>   
> +Item: ``GRE_OPTION``
> +^^^^^^^^^^^^^^^^^^^^
> +
> +Matches a GRE optional fields (checksum/key/sequence).
> +This should be preceded by item ``GRE``.
> +
> +- ``checksum``: checksum.
> +- ``key``: key.
> +- ``sequence``: sequence.
> +- The items in GRE_OPTION do not change bit flags(c_bit/k_bit/s_bit) in GRE
> +  item. The bit flags need be set with GRE item by application. When the items
> +  present, the corresponding bits in GRE spec and mask should be set "1" by
> +  application, it means to match specified value of the fields. When the items
> +  no present, but the corresponding bits in GRE spec and mask is "1", it means
> +  to match any value of the fields.
> +
>   Item: ``FUZZY``
>   ^^^^^^^^^^^^^^^
>   
> diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
> index a93f68a..03bd1df 100644
> --- a/lib/ethdev/rte_flow.c
> +++ b/lib/ethdev/rte_flow.c
> @@ -139,6 +139,7 @@ struct rte_flow_desc_data {
>   	MK_FLOW_ITEM(META, sizeof(struct rte_flow_item_meta)),
>   	MK_FLOW_ITEM(TAG, sizeof(struct rte_flow_item_tag)),
>   	MK_FLOW_ITEM(GRE_KEY, sizeof(rte_be32_t)),
> +	MK_FLOW_ITEM(GRE_OPTION, sizeof(struct rte_gre_hdr_option)),
>   	MK_FLOW_ITEM(GTP_PSC, sizeof(struct rte_flow_item_gtp_psc)),
>   	MK_FLOW_ITEM(PPPOES, sizeof(struct rte_flow_item_pppoe)),
>   	MK_FLOW_ITEM(PPPOED, sizeof(struct rte_flow_item_pppoe)),
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index 1031fb2..27b4140 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -660,6 +660,13 @@ enum rte_flow_item_type {
>   	 * See struct rte_flow_item_ppp.
>   	 */
>   	RTE_FLOW_ITEM_TYPE_PPP,
> +
> +	/**
> +	 * Matches GRE optional fields.
> +	 *
> +	 * See struct rte_gre_hdr_option.
> +	 */
> +	RTE_FLOW_ITEM_TYPE_GRE_OPTION,
>   };
>   
>   /**
> @@ -1196,6 +1203,17 @@ struct rte_flow_item_gre {
>   #endif
>   
>   /**
> + * RTE_FLOW_ITEM_TYPE_GRE_OPTION.
> + *
> + * Matches GRE optional fields in header.
> + */
> +struct rte_gre_hdr_option {
> +	rte_be16_t checksum;
> +	rte_be32_t key;
> +	rte_be32_t sequence;
> +};
> +

Hi Ori, Andrew,

The decision was to have protocol structs in the net library and flow structs
use from there, wasn't it?
(Btw, a deprecation notice is still pending to clear some existing ones)

So for the GRE optional fields, what about having a struct in the 'rte_gre.h'?
(Also perhaps an GRE extended protocol header can be defined combining
'rte_gre_hdr' and optional fields struct.)
Later flow API struct can embed that struct.