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

[Olivier Matz <olivier.matz@6wind.com>]

Hi Beilei,

On Mon, 12 Jun 2017 08:45:43 +0000, "Xing, Beilei" <beilei.xing@intel.com> 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 <bruce.richardson@intel.com>
> > Cc: Zhang, Helin <helin.zhang@intel.com>; Wu, Jingjing
> > <jingjing.wu@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.richardson@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