From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 06F103DC for ; Mon, 12 Jun 2017 18:25:38 +0200 (CEST) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jun 2017 09:25:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,334,1493708400"; d="scan'208";a="113897070" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga006.fm.intel.com with ESMTP; 12 Jun 2017 09:25:37 -0700 Received: from fmsmsx102.amr.corp.intel.com (10.18.124.200) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 12 Jun 2017 09:25:37 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX102.amr.corp.intel.com (10.18.124.200) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 12 Jun 2017 09:25:37 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.116]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.122]) with mapi id 14.03.0319.002; Tue, 13 Jun 2017 00:25:35 +0800 From: "Wu, Jingjing" To: "Wu, Jingjing" , 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+UFJsHZxugEO6Kasnp7QyaaIaNfMAgAADUwCABjC3gIAAELQAgADs8ZCAAAjSoA== Date: Mon, 12 Jun 2017 16:25:35 +0000 Message-ID: <9BB6961774997848B5B42BEC655768F810DA2005@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> <9BB6961774997848B5B42BEC655768F810DA1EDA@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <9BB6961774997848B5B42BEC655768F810DA1EDA@SHSMSX103.ccr.corp.intel.com> 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 16:25:39 -0000 Please ignore the empty mail. > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wu, Jingjing > Sent: Monday, June 12, 2017 11:54 PM > To: Olivier Matz ; Xing, Beilei > Cc: Richardson, Bruce ; Zhang, Helin ; > dev@dpdk.org > Subject: Re: [dpdk-dev] i40e: pci probe fails when using one bogus sfp >=20 >=20 >=20 > > -----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 > > > > Hi Beilei, > > > > 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 = sfp > > > > > > > > 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 i= s 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 p= robe > > > > > 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 menti= oned. > > > 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 th= e second port still can finish > > initialization successfully. I thought 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 > > > > > > Thank you for your quick answer. > > > > Yes, the pci probing continues for the other ports even if one port > > failed (since v17.05, commit 10f6c93cea). > > > > 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? > > > > In case of failure, it shifts the port ids of next ports, making it > > harder to recognize them in the application. > > > > With current code, after a failure, if the user replaces the faulty SFP > > after the application is started, it requires the application to suppor= t > > hotplug to ask to probe the PCI again to make the port appear again. > > > > If the failure is moved in the port start function, it would just > > require the application to start the port again. > > > > > > Regards > > Olivier