[dpdk-dev] i40e: pci probe fails when using one bogus sfp

[Wu, Jingjing]

Please ignore the empty mail.

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wu, Jingjing
> Sent: Monday, June 12, 2017 11:54 PM
> To: Olivier Matz <olivier.matz at 6wind.com>; Xing, Beilei <beilei.xing at intel.com>
> Cc: Richardson, Bruce <bruce.richardson at intel.com>; Zhang, Helin <helin.zhang at intel.com>;
> dev at dpdk.org
> Subject: Re: [dpdk-dev] i40e: pci probe fails when using one bogus sfp
> 
> 
> 
> > -----Original Message-----
> > From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> > Sent: Monday, June 12, 2017 5:46 PM
> > To: Xing, Beilei <beilei.xing at intel.com>
> > Cc: Richardson, Bruce <bruce.richardson at intel.com>; Zhang, Helin
> <helin.zhang at intel.com>;
> > Wu, Jingjing <jingjing.wu at intel.com>; dev at 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.xing at intel.com> wrote:
> > > Hi Olivier,
> > >
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz
> > > > Sent: Thursday, June 8, 2017 6:14 PM
> > > > To: Richardson, Bruce <bruce.richardson at intel.com>
> > > > Cc: Zhang, Helin <helin.zhang at intel.com>; Wu, Jingjing
> > > > <jingjing.wu at intel.com>; dev at 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.richardson at 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