From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E1E68A0C4D for ; Mon, 6 Sep 2021 11:37:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AD19840C35; Mon, 6 Sep 2021 11:37:29 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id F149940C35 for ; Mon, 6 Sep 2021 11:37:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1630921047; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tqp6RJBvgCS5A5Gk1zQ7FOYToFyGcsVj8sZ0T4MLWw0=; b=bIzXaHPmlcV/1rKNPwAe1eT+jlSSqCII/4prdyz/1Hnz2hslu0wCNsqcuS3iK2rf/sk7B5 CN0UUuoEsTfNeFXAT88h168lAJghE9lD2POHhGTzk4SrHxouIQOpDyG60F/vDY9NdtzdFZ t/8QTwlh2GIjQgLTswZ0/XWDDxPLtaw= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-214-zF0QvjAfNCGUFG76KjNVlw-1; Mon, 06 Sep 2021 05:37:23 -0400 X-MC-Unique: zF0QvjAfNCGUFG76KjNVlw-1 Received: by mail-lj1-f199.google.com with SMTP id p11-20020a2ea40b000000b001d68cffb055so3105857ljn.6 for ; Mon, 06 Sep 2021 02:37:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tqp6RJBvgCS5A5Gk1zQ7FOYToFyGcsVj8sZ0T4MLWw0=; b=WXadU5QaL/duMC4F9K9hn75ZkHlaRPlHzegeCU2nkKkxnfkoc/5bAdgE3OomkAQqoi g+cTeOHqpmIseLFzWSXjVfXq3dtqJbrphe5jGXgzU1MpPytlc+oNA5lJolqLZh0Xy2Hl 09/vUxmLrZvM6hdrA/6eFvIjRGafWN1nW7jxguwyXKBk/75OLOAQxb+FxPppddN7ZJXP lx2QJaNGKoB1TjWg5wNpu4NJuN7FLWHrTJT1rJujErYeyUmfUpYmxkv5kXHSmOHXHNR/ tR0RrWeSULzCKepG92WSL+EcKgxzICtnaiWQYzlm2p1/l8pcor03jxZaeLyfBzg0kj6d wnPQ== X-Gm-Message-State: AOAM532OTnMswBASiW/5kPm06opCE2Dj/ryfzBRKbjD+vsQaUE41hIDD Ah+sAz/FrbXquNED7Gpx6YcS0NFlcrMiIaGyURdbjBl1nyqyGCQV7Y6sdzDfTmEEpBmfNrXlPkE zKlPaKIKlrLHEAij16T4o49E= X-Received: by 2002:a2e:b0ee:: with SMTP id h14mr9609197ljl.297.1630921041535; Mon, 06 Sep 2021 02:37:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxtiGn9BW1+n9mRMPzPwT9H6NKCccpaKA1P5BemO7SmFYZD6cOMITG9kK9ExdlQMJZ/VQ9VeztO5VRQi2JU/gg= X-Received: by 2002:a2e:b0ee:: with SMTP id h14mr9609170ljl.297.1630921041169; Mon, 06 Sep 2021 02:37:21 -0700 (PDT) MIME-Version: 1.0 References: <20210906070751.9750-1-chenqiming_huawei@163.com> In-Reply-To: <20210906070751.9750-1-chenqiming_huawei@163.com> From: David Marchand Date: Mon, 6 Sep 2021 11:37:09 +0200 Message-ID: To: Qiming Chen Cc: dev , Beilei Xing , dpdk stable , Qiming Yang , Qi Zhang , Jingjing Wu , "Yigit, Ferruh" Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-stable] [PATCH] net/i40e: extend the polling times of vf reset X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Mon, Sep 6, 2021 at 9:08 AM Qiming Chen 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 > --- > 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) -- David Marchand