From: Olivier Matz <olivier.matz@6wind.com>
To: "Xing, Beilei" <beilei.xing@intel.com>
Cc: "Richardson, Bruce" <bruce.richardson@intel.com>,
"Zhang, Helin" <helin.zhang@intel.com>,
"Wu, Jingjing" <jingjing.wu@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] i40e: pci probe fails when using one bogus sfp
Date: Mon, 12 Jun 2017 11:45:30 +0200 [thread overview]
Message-ID: <20170612114530.0eab4314@platinum> (raw)
In-Reply-To: <94479800C636CB44BD422CB454846E0131FC734C@SHSMSX101.ccr.corp.intel.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
next prev parent reply other threads:[~2017-06-12 9:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-08 9:29 Olivier Matz
2017-06-08 10:01 ` Bruce Richardson
2017-06-08 10:13 ` Olivier Matz
2017-06-12 8:45 ` Xing, Beilei
2017-06-12 9:45 ` Olivier Matz [this message]
2017-06-12 15:53 ` Wu, Jingjing
2017-06-12 16:25 ` Wu, Jingjing
2017-06-12 16:23 ` Wu, Jingjing
2017-06-13 8:27 ` Olivier MATZ
2017-06-13 14:14 ` Wu, Jingjing
2017-06-15 9:03 ` Olivier MATZ
2017-06-15 9:08 ` [dpdk-dev] [PATCH] net/i40e: avoid PCI probing failure when using " Olivier Matz
2017-06-23 9:25 ` Wu, Jingjing
2017-06-23 10:11 ` Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170612114530.0eab4314@platinum \
--to=olivier.matz@6wind.com \
--cc=beilei.xing@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=helin.zhang@intel.com \
--cc=jingjing.wu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).