DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Wu, Jingjing" <jingjing.wu@intel.com>
To: "Wu, Jingjing" <jingjing.wu@intel.com>,
	Olivier Matz <olivier.matz@6wind.com>,
	"Xing, Beilei" <beilei.xing@intel.com>
Cc: "Richardson, Bruce" <bruce.richardson@intel.com>,
	"Zhang, Helin" <helin.zhang@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 16:25:35 +0000	[thread overview]
Message-ID: <9BB6961774997848B5B42BEC655768F810DA2005@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <9BB6961774997848B5B42BEC655768F810DA1EDA@SHSMSX103.ccr.corp.intel.com>

Please ignore the empty mail.

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wu, Jingjing
> Sent: Monday, June 12, 2017 11:54 PM
> To: Olivier Matz <olivier.matz@6wind.com>; Xing, Beilei <beilei.xing@intel.com>
> Cc: Richardson, Bruce <bruce.richardson@intel.com>; Zhang, Helin <helin.zhang@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.matz@6wind.com]
> > Sent: Monday, June 12, 2017 5:46 PM
> > 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
> > 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@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

  reply	other threads:[~2017-06-12 16:25 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
2017-06-12 15:53         ` Wu, Jingjing
2017-06-12 16:25           ` Wu, Jingjing [this message]
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=9BB6961774997848B5B42BEC655768F810DA2005@SHSMSX103.ccr.corp.intel.com \
    --to=jingjing.wu@intel.com \
    --cc=beilei.xing@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=helin.zhang@intel.com \
    --cc=olivier.matz@6wind.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).