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

Xing, Beilei beilei.xing at intel.com
Mon Jun 12 10:45:43 CEST 2017


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

Beilei

> 
> > Can that one problem
> > port not just be blacklisted, since it's presumably unusable anyway?
> 
> This would imply the user (or the manager program) that launches the
> application to parse the logs to detect which port fails and update the
> configuration accordingly.
> 
> I think it would be better to return an error at port initialization, so that the
> application can takes its dispositions directly. We could even imagine that the
> port could be reenabled later once the SFP is changed, without restarting the
> application.
> 
> 
> Olivier


More information about the dev mailing list