From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) by dpdk.org (Postfix) with ESMTP id AAC0E2A58 for ; Mon, 12 Jun 2017 11:45:33 +0200 (CEST) Received: by mail-wr0-f170.google.com with SMTP id v111so90041324wrc.3 for ; Mon, 12 Jun 2017 02:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ScsyK+FXceKUfnrmURnGUlgulYdehruLHJL9NLIP3oU=; b=rhxiKJzC/PdudwaxEWZC/UoVVsC88XuqkEg+b27BhqwO5km+Ish3WsQHIFQ8qL9yot oSNrQPIzaDiSvzip4bBiXoioQAagIC21JEV/vj8zc/TNIMATBuImmAy7fySIHeVNCa6v /e17amvqftLwQGcIp7Z9xh15Hg+BYYLaITrRwgzejxcTIMuuN4dhKukGSbgG34cOkcXm swp/uvaTzHef/xrlSoWq8WH4F+uzVlaoIoWquHs/mi6/C4ia17ZglnkmzDdOQp+RYALA mSScmZIxvatNoMxRZrlcS/SxtWAOkauaEQFhNGD8EunU6yoE7E034RmMt046idQLtDFp ckrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ScsyK+FXceKUfnrmURnGUlgulYdehruLHJL9NLIP3oU=; b=XREjQpuFRfS0CVtUYrbqZ5WmZx5lWeY3paAVg6gjzFzGU9F9jlFyNFLueZtfLx+F+U dt8VCkBlen3oOx7zLz/j/O5I+5VT0A470AhXm6nqFX91BosRN+5wrtwed4kzr/UoL++b mwEsOy1DmgMI8Mz+XOe2070YkYXF1yM0he0INtxQPDngUI4TlrccE2Ru0pBy641vfiVM Z1hT5ak0GCyqU+heWqjLDGx/GGXV+8hoAkqqNnFvNljdQjCqEUjqlZF+qJ8S/DtfOqsN SPWyjnDUe9ZVhdq2MUpOCuIg0HM9AduvaoEIyBJa1BQIE35hm/V83hGV6wJ9CPnaHaDs 5T9g== X-Gm-Message-State: AODbwcBl6LQDyFSDlgHqE4Y79ZhUAKqgvMqFi+udr5GT0QbL2/fVbSeA uu6WahIpBowBiKYy X-Received: by 10.223.176.205 with SMTP id j13mr6396601wra.65.1497260733305; Mon, 12 Jun 2017 02:45:33 -0700 (PDT) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id u4sm593722wmf.7.2017.06.12.02.45.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 12 Jun 2017 02:45:33 -0700 (PDT) Date: Mon, 12 Jun 2017 11:45:30 +0200 From: Olivier Matz To: "Xing, Beilei" Cc: "Richardson, Bruce" , "Zhang, Helin" , "Wu, Jingjing" , "dev@dpdk.org" Message-ID: <20170612114530.0eab4314@platinum> In-Reply-To: <94479800C636CB44BD422CB454846E0131FC734C@SHSMSX101.ccr.corp.intel.com> References: <20170608112917.22fb51eb@platinum> <20170608100154.GA56168@bricha3-MOBL3.ger.corp.intel.com> <20170608121348.5c2f538a@platinum> <94479800C636CB44BD422CB454846E0131FC734C@SHSMSX101.ccr.corp.intel.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] i40e: pci probe fails when using one bogus sfp X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 09:45:33 -0000 Hi Beilei, On Mon, 12 Jun 2017 08:45:43 +0000, "Xing, Beilei" 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 > > Cc: Zhang, Helin ; Wu, Jingjing > > ; 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 > > 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