[v2] net/i40e: fix flex payload rule conflict issue

  From: Beilei Xing <beilei.xing@intel.com>

With the following commands, the second flow can't
be created successfully.

1. flow create 0 ingress pattern eth / ipv4 / udp /
   raw relative is 1 pattern is 0102030405 / end
   actions drop / end
2. flow destroy 0 rule 0
3. flow create 0 ingress pattern eth / ipv4 / udp /
   raw relative is 1 pattern is 010203040506 / end
   actions drop / end

The root cause is that a flag for flex pit isn't reset.

Fixes: 6ced3dd72f5f ("net/i40e: support flexible payload parsing for FDIR")
Cc: stable@dpdk.org

Reported-by: Chenmin Sun<chenmin.sun@intel.com>
Signed-off-by: Beilei Xing <beilei.xing@intel.com>
---

v2 changes:
 - Add fix line.
 - Refine comments.

 drivers/net/i40e/i40e_flow.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)
  

Hi, beilei

> -----Original Message-----
> From: Xing, Beilei <beilei.xing@intel.com>
> Sent: Tuesday, December 29, 2020 2:18 PM
> To: Guo, Jia <jia.guo@intel.com>; dev@dpdk.org
> Cc: Xing, Beilei <beilei.xing@intel.com>; stable@dpdk.org; Sun, Chenmin
> <chenmin.sun@intel.com>
> Subject: [PATCH v2] net/i40e: fix flex payload rule conflict issue
> 
> From: Beilei Xing <beilei.xing@intel.com>
> 
> With the following commands, the second flow can't be created successfully.
> 
> 1. flow create 0 ingress pattern eth / ipv4 / udp /
>    raw relative is 1 pattern is 0102030405 / end
>    actions drop / end
> 2. flow destroy 0 rule 0
> 3. flow create 0 ingress pattern eth / ipv4 / udp /
>    raw relative is 1 pattern is 010203040506 / end
>    actions drop / end
> 
> The root cause is that a flag for flex pit isn't reset.
> 
> Fixes: 6ced3dd72f5f ("net/i40e: support flexible payload parsing for FDIR")
> Cc: stable@dpdk.org
> 
> Reported-by: Chenmin Sun<chenmin.sun@intel.com>
> Signed-off-by: Beilei Xing <beilei.xing@intel.com>
> ---
> 
> v2 changes:
>  - Add fix line.
>  - Refine comments.
> 
>  drivers/net/i40e/i40e_flow.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/i40e/i40e_flow.c b/drivers/net/i40e/i40e_flow.c
> index b09ff6590d..65e0b69356 100644
> --- a/drivers/net/i40e/i40e_flow.c
> +++ b/drivers/net/i40e/i40e_flow.c
> @@ -5284,6 +5284,7 @@ i40e_flow_destroy(struct rte_eth_dev *dev,
>  	enum rte_filter_type filter_type = flow->filter_type;
>  	struct i40e_fdir_info *fdir_info = &pf->fdir;
>  	int ret = 0;
> +	int i;
> 
>  	switch (filter_type) {
>  	case RTE_ETH_FILTER_ETHERTYPE:
> @@ -5299,9 +5300,13 @@ i40e_flow_destroy(struct rte_eth_dev *dev,
>  				&((struct i40e_fdir_filter *)flow->rule)->fdir,
>  				0);
> 
> -		/* If the last flow is destroyed, disable fdir. */
> +		/* When the last flow is destroyed. */
>  		if (!ret && TAILQ_EMPTY(&pf->fdir.fdir_list)) {
> +			/* Disable FDIR processing. */
>  			i40e_fdir_rx_proc_enable(dev, 0);
> +			/* Reset the flex_pit_flag. */
> +			for (i = 0; i < I40E_MAX_FLXPLD_LAYER; i++)
> +				pf->fdir.flex_pit_flag[i] = 0;

Why reset all flex_pit_flag when destroy the last flow, if destroy other flow, is it no need to reset corresponding flex_pit_flag which set before when the flow added?
And reset flag should be ahead of the FDIR disabling I think.

>  		}
>  		break;
>  	case RTE_ETH_FILTER_HASH:
> @@ -5515,6 +5520,9 @@ i40e_flow_flush_fdir_filter(struct i40e_pf *pf)
>  			pf->fdir.flex_mask_flag[pctype] = 0;
>  		}
> 
> +		for (i = 0; i < I40E_MAX_FLXPLD_LAYER; i++)
> +			pf->fdir.flex_pit_flag[i] = 0;
> +
>  		/* Disable FDIR processing as all FDIR rules are now flushed
> */
>  		i40e_fdir_rx_proc_enable(dev, 0);
>  	}
> --
> 2.26.2