From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 5FC953DC for ; Mon, 12 Jun 2017 17:53:45 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jun 2017 08:53:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,334,1493708400"; d="scan'208";a="867083892" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by FMSMGA003.fm.intel.com with ESMTP; 12 Jun 2017 08:53:45 -0700 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 12 Jun 2017 08:53:44 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX114.amr.corp.intel.com (10.18.116.8) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 12 Jun 2017 08:53:44 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.116]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.56]) with mapi id 14.03.0319.002; Mon, 12 Jun 2017 23:53:41 +0800 From: "Wu, Jingjing" To: Olivier Matz , "Xing, Beilei" CC: "Richardson, Bruce" , "Zhang, Helin" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] i40e: pci probe fails when using one bogus sfp Thread-Index: AQHS4Dm+UFJsHZxugEO6Kasnp7QyaaIaNfMAgAADUwCABjC3gIAAELQAgADs8ZA= Date: Mon, 12 Jun 2017 15:53:40 +0000 Message-ID: <9BB6961774997848B5B42BEC655768F810DA1EDA@SHSMSX103.ccr.corp.intel.com> References: <20170608112917.22fb51eb@platinum> <20170608100154.GA56168@bricha3-MOBL3.ger.corp.intel.com> <20170608121348.5c2f538a@platinum> <94479800C636CB44BD422CB454846E0131FC734C@SHSMSX101.ccr.corp.intel.com> <20170612114530.0eab4314@platinum> In-Reply-To: <20170612114530.0eab4314@platinum> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action 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 15:53:47 -0000 > -----Original Message----- > From: Olivier Matz [mailto:olivier.matz@6wind.com] > Sent: Monday, June 12, 2017 5:46 PM > To: Xing, Beilei > Cc: Richardson, Bruce ; Zhang, Helin ; > Wu, Jingjing ; dev@dpdk.org > Subject: Re: [dpdk-dev] i40e: pci probe fails when using one bogus sfp >=20 > Hi Beilei, >=20 > On Mon, 12 Jun 2017 08:45:43 +0000, "Xing, Beilei" wrote: > > 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 sf= p > > > > > > 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 pro= be > > > > is terminating after the failure on the error port? > > > > > > Yes, the probe is terminating > > > > Sorry I'm not very clear about the termination of PCI probe you mention= ed. > > I did some test in current code base: there're two ports (87:00.0 and 8= 7: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 thought it has met your request. Please co= rrect 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 >=20 >=20 > Thank you for your quick answer. >=20 > Yes, the pci probing continues for the other ports even if one port > failed (since v17.05, commit 10f6c93cea). >=20 > But I find a bit strange to have this check about the SFP in the > PCI probing function instead of having it the port initialization > function. My understanding is the SFP check is not related to PCI > probing. Is it consistent with other drivers? >=20 > In case of failure, it shifts the port ids of next ports, making it > harder to recognize them in the application. >=20 > With current code, after a failure, if the user replaces the faulty SFP > after the application is started, it requires the application to support > hotplug to ask to probe the PCI again to make the port appear again. >=20 > If the failure is moved in the port start function, it would just > require the application to start the port again. >=20 >=20 > Regards > Olivier