From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id B6CF39E3 for ; Mon, 12 Jun 2017 10:45:49 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP; 12 Jun 2017 01:45:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,333,1493708400"; d="scan'208";a="866961695" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by FMSMGA003.fm.intel.com with ESMTP; 12 Jun 2017 01:45:47 -0700 Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 12 Jun 2017 01:45:47 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx116.amr.corp.intel.com (10.18.116.20) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 12 Jun 2017 01:45:47 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.197]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.56]) with mapi id 14.03.0319.002; Mon, 12 Jun 2017 16:45:43 +0800 From: "Xing, Beilei" To: Olivier Matz , "Richardson, Bruce" CC: "Zhang, Helin" , "Wu, Jingjing" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] i40e: pci probe fails when using one bogus sfp Thread-Index: AQHS4Dnj80bYd/pPc0yxnITu83z1rqIaNfMAgAADUwCABrArYA== Date: Mon, 12 Jun 2017 08:45:43 +0000 Message-ID: <94479800C636CB44BD422CB454846E0131FC734C@SHSMSX101.ccr.corp.intel.com> References: <20170608112917.22fb51eb@platinum> <20170608100154.GA56168@bricha3-MOBL3.ger.corp.intel.com> <20170608121348.5c2f538a@platinum> In-Reply-To: <20170608121348.5c2f538a@platinum> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] i40e: pci probe fails when using one bogus sfp X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 08:45:50 -0000 Hi Olivier, > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz > Sent: Thursday, June 8, 2017 6:14 PM > To: Richardson, Bruce > Cc: Zhang, Helin ; Wu, Jingjing > ; dev@dpdk.org > Subject: Re: [dpdk-dev] i40e: pci probe fails when using one bogus sfp >=20 > On Thu, 8 Jun 2017 11:01:54 +0100, Bruce Richardson > wrote: > > On Thu, Jun 08, 2017 at 11:29:17AM +0200, Olivier Matz wrote: > > > Hi, > > > > > > One of our customers encounters an issue with dpdk when there is a > > > bogus SFP on one of the ports. The following message is > > > reported: > > > > > > PMD: eth_i40e_dev_init(): Failed to sync phy type: -95 > > > > > > (note: 95 is EOPNOTSUPP/ENOTSUP) > > > > > > Unfortunately I cannot reproduce the issue to give more details, but > > > the hypothesis is that it fails in i40e_dev_sync_phy_type(). > > > It could be related to that patch: > > > > > > http://dpdk.org/browse/dpdk/commit/?id=3Dedfb226f69bf > > > > > > To me, the expected behavior should be: > > > - pci probe is succesful > > > - the initialization of the port with faulty SFP fails > > > - the initialization of the other ports is succesful > > > > > > Do you have any comment or idea to fix this issue? > > > > > And what is the current behaviour you are seeing? The whole PCI probe > > is terminating after the failure on the error port? >=20 > Yes, the probe is terminating Sorry I'm not very clear about the termination of PCI probe you mentioned. I did some test in current code base: there're two ports (87:00.0 and 87:00= .2)bound to igb_uio, and force the first port to fail to initialize, I find= that the second port still can finish initialization successfully. I thoug= ht it has met your request. Please correct me if I'm wrong. EAL: PCI device 0000:87:00.0 on NUMA socket -1 EAL: probe driver: 8086:1572 net_i40e ~failed eth_i40e_dev_init(): Failed to sync phy type: 0 EAL: PCI device 0000:87:00.1 on NUMA socket -1 EAL: probe driver: 8086:1572 net_i40e EAL: PCI device 0000:87:00.2 on NUMA socket -1 EAL: probe driver: 8086:1572 net_i40e ~succeed Beilei >=20 > > Can that one problem > > port not just be blacklisted, since it's presumably unusable anyway? >=20 > This would imply the user (or the manager program) that launches the > application to parse the logs to detect which port fails and update the > configuration accordingly. >=20 > I think it would be better to return an error at port initialization, so = that the > application can takes its dispositions directly. We could even imagine th= at the > port could be reenabled later once the SFP is changed, without restarting= the > application. >=20 >=20 > Olivier