Please ignore the empty mail.
> -----Original Message----- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wu, Jingjing > Sent: Monday, June 12, 2017 11:54 PM > To: Olivier Matz <olivier.m...@6wind.com>; Xing, Beilei > <beilei.x...@intel.com> > Cc: Richardson, Bruce <bruce.richard...@intel.com>; Zhang, Helin > <helin.zh...@intel.com>; > dev@dpdk.org > Subject: Re: [dpdk-dev] i40e: pci probe fails when using one bogus sfp > > > > > -----Original Message----- > > From: Olivier Matz [mailto:olivier.m...@6wind.com] > > Sent: Monday, June 12, 2017 5:46 PM > > To: Xing, Beilei <beilei.x...@intel.com> > > Cc: Richardson, Bruce <bruce.richard...@intel.com>; Zhang, Helin > <helin.zh...@intel.com>; > > Wu, Jingjing <jingjing...@intel.com>; 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" <beilei.x...@intel.com> > > wrote: > > > Hi Olivier, > > > > > > > -----Original Message----- > > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Olivier Matz > > > > Sent: Thursday, June 8, 2017 6:14 PM > > > > To: Richardson, Bruce <bruce.richard...@intel.com> > > > > Cc: Zhang, Helin <helin.zh...@intel.com>; Wu, Jingjing > > > > <jingjing...@intel.com>; 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 > > > > <bruce.richard...@intel.com> 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=edfb226f69bf > > > > > > > > > > > > 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? > > > > > > > > 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 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 support > > 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
