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 8E798A0351 for ; Mon, 10 Jan 2022 10:29:16 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 94C45426D2; Mon, 10 Jan 2022 10:29:12 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 775FA4013F; Mon, 10 Jan 2022 10:29:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1641806949; x=1673342949; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=owxlJrP6wdsvUeAJz9ALaKjwyjXDYttUjEzkusNeVPQ=; b=KBO5prsHvc+OXSJUUxriu71ZLV9gxLbIWDodxfG7vGN3A3gmP1O8aFpw pKOSPnaNT86j7jX7x9SGJ6ZlX1NjnUr37jb+mbNo+Wu0UicoftDfJoRsv uloxacrZHrhLmLXxnoVpTgn/eklVDB+Ym3tvQm8iyv4Tb/VJZSBiTigrl Kvyvs8m7sFELCgRNoldQRyYTfd3S3llXz9rytYlKolcpUx+k3jURa0zss U5mppe7fC373PlXc+4O8980gKtGxDFFnOrtHO1/Sh86MjuP3U4bFY63ll NSzUlPoY+Ijd5RmwcXWTYBEkt8kbh69pdRBVEZjaKrdAiDek9czYU7kWr g==; X-IronPort-AV: E=McAfee;i="6200,9189,10222"; a="267516944" X-IronPort-AV: E=Sophos;i="5.88,276,1635231600"; d="scan'208";a="267516944" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jan 2022 01:29:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,276,1635231600"; d="scan'208";a="592306246" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by fmsmga004.fm.intel.com with ESMTP; 10 Jan 2022 01:29:08 -0800 Received: from shsmsx603.ccr.corp.intel.com (10.109.6.143) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Mon, 10 Jan 2022 01:29:07 -0800 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX603.ccr.corp.intel.com (10.109.6.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Mon, 10 Jan 2022 17:29:05 +0800 Received: from shsmsx601.ccr.corp.intel.com ([10.109.6.141]) by SHSMSX601.ccr.corp.intel.com ([10.109.6.141]) with mapi id 15.01.2308.020; Mon, 10 Jan 2022 17:29:05 +0800 From: "Zhang, Qi Z" To: wangyunjian , "dev@dpdk.org" , "users@dpdk.org" , "Yang, Qiming" CC: Huangshaozhang , dingxiaoxiong Subject: RE: [dpdk-dev] [dpdk-users] A question about the link status of the intel E810 nic can not be up? Thread-Topic: [dpdk-dev] [dpdk-users] A question about the link status of the intel E810 nic can not be up? Thread-Index: AdgF0Pn/6qGT4vxjTVSzS48+AOJr4gAMyjXw Date: Mon, 10 Jan 2022 09:29:05 +0000 Message-ID: <559e14c286d240caa7e1649df9664843@intel.com> References: <41f0c2c9f77348fbb22dad35ef155536@huawei.com> In-Reply-To: <41f0c2c9f77348fbb22dad35ef155536@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.6.200.16 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org > -----Original Message----- > From: wangyunjian > Sent: Monday, January 10, 2022 11:20 AM > To: dev@dpdk.org; users@dpdk.org; Yang, Qiming ; > Zhang, Qi Z > Cc: Huangshaozhang ; dingxiaoxiong > > Subject: [dpdk-dev] [dpdk-users] A question about the link status of the = intel > E810 nic can not be up? >=20 > Hi, All: >=20 > I am using Intel E810 with DPDK v21.11 to create a dpdkbond but there is = a > probability that the failure will occur. >=20 > During the test, the bonding is repeatedly added and deleted. Sometimes, = the > link status of the NIC is Down. And if call ice_dev_set_link_up again, th= e link > status of the NIC can be recovered. >=20 > Alternatively, the problem can be avoided by modifying the ice pmd driver= . >=20 > diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c = index > 13a7a9702a..fcd22e20a5 100644 > --- a/drivers/net/ice/ice_ethdev.c > +++ b/drivers/net/ice/ice_ethdev.c > @@ -3604,7 +3604,7 @@ ice_dev_start(struct rte_eth_dev *dev) > ice_dev_set_link_up(dev); >=20 > /* Call get_link_info aq commond to enable/disable LSE */ > - ice_link_update(dev, 0); > + ice_link_update(dev, 1); This looks good to me, it's reasonable to wait for complete right after set= link up as it is not in an link status change interrupt handling scenario. We will try to reproduce this issue, meanwhile could you help on following = below 2 things. 1. share the device ID / firmware version that you met this issue. 2. send a v2 with reworded title and commit log as a normal patch if you wa= nt to contribute. Thanks Qi >=20 > pf->adapter_stopped =3D false;