net/i40e: extend the polling times of vf reset

  In the embedded RTOS environment, the x722 controller Ethernet card of
the d2146nt chip, the vfio user mode driver takes over 8 vf ports in
turn, but i40evf_check_vf_reset_done will probably fail.

This issue has been discussed with intel&dpdk experts for 3 rounds
before, and the version matching is no problem, and there is no
substantial progress. The official website contacted external experts,
but there was no response afterwards. Learning from the implementation
of the i40evf kernel driver locally, after modifying the polling time
from 1 second to 5s, the repeated restart process took over the start
port test, and it was found that this probability was reduced to an
order of magnitude acceptable to the user.

The patch cannot fundamentally solve the failure problem, but it greatly
slows down the probability of the problem. The modification is based on the
i40evf kernel driver.

Fixes: 5c9222058df7 ("i40e: move to drivers/net/")
Cc: stable@dpdk.org

Signed-off-by: Qiming Chen <chenqiming_huawei@163.com>
---
 drivers/net/i40e/i40e_ethdev_vf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

On Mon, Sep 6, 2021 at 9:08 AM Qiming Chen <chenqiming_huawei@163.com> wrote:
>
> In the embedded RTOS environment, the x722 controller Ethernet card of
> the d2146nt chip, the vfio user mode driver takes over 8 vf ports in
> turn, but i40evf_check_vf_reset_done will probably fail.
>
> This issue has been discussed with intel&dpdk experts for 3 rounds
> before, and the version matching is no problem, and there is no
> substantial progress. The official website contacted external experts,
> but there was no response afterwards. Learning from the implementation
> of the i40evf kernel driver locally, after modifying the polling time
> from 1 second to 5s, the repeated restart process took over the start
> port test, and it was found that this probability was reduced to an
> order of magnitude acceptable to the user.
>
> The patch cannot fundamentally solve the failure problem, but it greatly
> slows down the probability of the problem. The modification is based on the
> i40evf kernel driver.
>
> Fixes: 5c9222058df7 ("i40e: move to drivers/net/")

This Fixes: is not the right one as this commit only moved code around.


> Cc: stable@dpdk.org
>
> Signed-off-by: Qiming Chen <chenqiming_huawei@163.com>
> ---
>  drivers/net/i40e/i40e_ethdev_vf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
> index f64db72e9a..924da8dfb4 100644
> --- a/drivers/net/i40e/i40e_ethdev_vf.c
> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> @@ -42,7 +42,7 @@
>  /* busy wait delay in msec */
>  #define I40EVF_BUSY_WAIT_DELAY 10
>  #define I40EVF_BUSY_WAIT_COUNT 50
> -#define MAX_RESET_WAIT_CNT     20
> +#define MAX_RESET_WAIT_CNT     100

Copying more Intel maintainers.

This mechanism is common to various Intel hw/drivers.
Does this issue only affect i40e hw or should we also consider the
issue with other hw/drivers?

drivers/net/i40e/i40e_ethdev_vf.c:#define MAX_RESET_WAIT_CNT     20
drivers/net/i40e/i40e_ethdev_vf.c:      for (i = 0; i <
MAX_RESET_WAIT_CNT; i++) {
drivers/net/i40e/i40e_ethdev_vf.c:      if (i >= MAX_RESET_WAIT_CNT)
drivers/net/iavf/iavf.h:#define IAVF_RESET_WAIT_CNT       50
drivers/net/iavf/iavf_ethdev.c: for (i = 0; i < IAVF_RESET_WAIT_CNT; i++) {
drivers/net/iavf/iavf_ethdev.c: if (i >= IAVF_RESET_WAIT_CNT)
drivers/net/ice/ice_dcf.c:#define ICE_DCF_RESET_WAIT_CNT       50
drivers/net/ice/ice_dcf.c:      for (i = 0; i < ICE_DCF_RESET_WAIT_CNT; i++) {
drivers/net/ice/ice_dcf.c:      if (i >= ICE_DCF_RESET_WAIT_CNT)