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 536DA5583 for ; Tue, 13 Jun 2017 16:14:48 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP; 13 Jun 2017 07:14:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,338,1493708400"; d="scan'208";a="273670797" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga004.fm.intel.com with ESMTP; 13 Jun 2017 07:14:47 -0700 Received: from fmsmsx121.amr.corp.intel.com (10.18.125.36) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 13 Jun 2017 07:14:47 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx121.amr.corp.intel.com (10.18.125.36) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 13 Jun 2017 07:14:47 -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; Tue, 13 Jun 2017 22:14:43 +0800 From: "Wu, Jingjing" To: Olivier MATZ CC: "Xing, Beilei" , "Richardson, Bruce" , "Zhang, Helin" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] i40e: pci probe fails when using one bogus sfp Thread-Index: AQHS4Dm+UFJsHZxugEO6Kasnp7QyaaIaNfMAgAADUwCABjC3gIAAELQAgADtBOCAAI+HgIAA5U3g Date: Tue, 13 Jun 2017 14:14:43 +0000 Message-ID: <9BB6961774997848B5B42BEC655768F810DA461C@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> <9BB6961774997848B5B42BEC655768F810DA1FAE@SHSMSX103.ccr.corp.intel.com> <20170613102731.518aa083@glumotte.dev.6wind.com> In-Reply-To: <20170613102731.518aa083@glumotte.dev.6wind.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: Tue, 13 Jun 2017 14:14:49 -0000 > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Tuesday, June 13, 2017 4:28 PM > To: Wu, Jingjing > Cc: Xing, Beilei ; Richardson, Bruce ; > Zhang, Helin ; dev@dpdk.org > Subject: Re: [dpdk-dev] i40e: pci probe fails when using one bogus sfp >=20 > Hi Jingjing, >=20 > On Mon, 12 Jun 2017 16:23:47 +0000, "Wu, Jingjing" wrote: > > HI, Olivier > > > > > 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? > > > > > Could your customer help to check what is the exactly error code is by > > Checking the "hw->aq.asq_last_status" when eth_i40e_dev_init() fails. >=20 > I'm afraid it won't be possible, since it's a random issue that is > not reproducible. >=20 > What do you think about adding a log in i40e_dev_sync_phy_type() to > display the status value in case of failure? It would help for next > times. I can submit a patch for that if you want. > Yes, It makes sense. Thanks for doing that. > > Yes, it seems better PHY init fails doesn't block PCI probe. Just compa= red with i40e > > Kernel version, PHY init fails doesn't block CPI probe. And there is wa= tchdog task to > > Check the PHY status. But DPDK is polling mode, If PCI probe fails, PCI= probe continues, > > then application need poll PHY status to support SFP change. >=20 > From what I understand, i40e_dev_sync_phy_type() was added > to know the PHY capabilities, which useful for instance for devinfo(). > Indeed, devinfo() can be call before the port is started, so > we need to have get the PHY capabilities before starting the port. >=20 > I've done a quick patch that: > - keeps the call to i40e_dev_sync_phy_type() in pci probing but > continue in case of failure > - add another call to i40e_dev_sync_phy_type() in port start > function > I think this workaround would not introduce issue if SFP is ready on NIC be= fore Probe. But I'm not sure if it can resolve the issue, because during probe, dozens = of initialization work Is ongoing. I think we need to verify it PHY init during start phase works = or not. Maybe we Need to do more than that? Not sure. > I think it would solve the issue without impacting the result > of the devinfo() function. What would you think of a patch like > this? >=20 > > And I also checked ixgbe driver, it seems phy init is done at probe tim= e. > > In my opinion, dev_start and dev_stop is meaning ready for receiving an= d transmitting > > packets, it may not be suitable to put it in the start/stop phase. >=20 > I'm wondering: what would/should occur if the SFP is unplugged and > replugged while the port is running? >=20 > I suppose we don't have any PCI notification when unplugging/plugging > the SFP, so I'm not sure we should have this check at the PCI level, > because the application does not know if the bus has to be probed again. > We can consider about unplugging/plugging as link event in DPDK. Now we have LSC or user can polling link status. Maybe that is a way to go. Thanks Jingjing