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 8351DA0C4D; Mon, 6 Sep 2021 11:37:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D3CE941104; 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 03BFF40E32 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-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-482-6l7Qr_Q4P0mS4i4hB9zYXw-1; Mon, 06 Sep 2021 05:37:23 -0400 X-MC-Unique: 6l7Qr_Q4P0mS4i4hB9zYXw-1 Received: by mail-lf1-f72.google.com with SMTP id k20-20020a05651239d400b003d91160994dso1548381lfu.1 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=BJXNl9vNa5OeW21BEXC1bU+TbPWyv93gEgLHxJnyGR6urbHmTTY8FMgksnHKPxtSES JbSK9NiZZnHPTmtl/R/0GpbCq97zxwgEdyH1SAkK44igwX9eXT42iWGmtSoAR9KRqOOc fykjclL6HoQCqFPZEVJ4d1rDbYmK2mz00crO9VECK03htTFeFdQsIZG5IEGN9ZRFFdAT N5hBmQYHVl0bnLcEdY3X6xYhnla5K9Z2MoshJu91LxfRbADYif6oOtw1J1aY9iX39DU4 7PZZxo7oWPI2W6t2umYsUZypanDT2M/5EiIvmdjT8MUogDkuRlx6aaqAVBazzRf13BhV cFMA== X-Gm-Message-State: AOAM533yKy/dJFdaZoAwD4y0DpsMbxil3mblr2vQ4a1ykCVmibNWXbdB bKp6vX7Ce0MU7Vh+cUUAtTfxOS6I5BJkQqvtfbNsWDpq0n8OhUZ2DjEezhI5VMdUUJpMFSB3cg+ 6HFMoQHAH7RHGFassvWU= X-Received: by 2002:a2e:b0ee:: with SMTP id h14mr9609188ljl.297.1630921041422; 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-dev] [dpdk-stable] [PATCH] net/i40e: extend the polling times of vf reset X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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