From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f181.google.com (mail-wr0-f181.google.com [209.85.128.181]) by dpdk.org (Postfix) with ESMTP id 1F47D377E for ; Thu, 15 Jun 2017 11:03:14 +0200 (CEST) Received: by mail-wr0-f181.google.com with SMTP id 36so12333150wry.3 for ; Thu, 15 Jun 2017 02:03:14 -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=NXiukmS4yzOVL1SY5m7/E1xsyGfjCgR9surC1M8Wvmk=; b=dJXD9Qm+KVcbocOrR8vj+CZkxxlHXFAIe/Ka5EbUpo1b2WK2mLkBwZEtPShh3Ya1q9 fSB6KmbxROu+yembxkcuLutDjgAukWxdnH9AokNOthHDmPrOO9lylOC6Eae+ahKVq+CU czbLol+6QPQlhAC/jzA3JLW2OMXlhgg6t+nS72oyPxdjoqcstLL955559SPfREln1HC3 RfduiJOZ6Ww18tRkLQSLlrmNKzFAEvW00KjwWVtxCCygaqj34IeFyS4GO3ktvYFt4lP+ JfWFCrpUUgHB0gFa1AoX8fCnVkme49x6U4ESLfrC8ZyhQ/HqZO1hPEpaAgh/cFrlkd/A wKYw== 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=NXiukmS4yzOVL1SY5m7/E1xsyGfjCgR9surC1M8Wvmk=; b=Ama61UI12Bn2lv4c8d8Fml6rRpBlmPhwu2v8cIeTtg3cWuav88vYVVKDR8LNsTxuqZ 0752SE7La9jauqpClp0/Nq7AoY7yazLxgML4WyP4lbBQKVBFU0nPOzqn/L2BIektXyuk ql2ijRMgL/KRVRjgmM/RI8gJb6QsNK2edqAyOyEgDP/OQ4B9jH6ez4iMDQ46aM1Oc4xg PFFE6/G6X43j1GPZbMRVInEkhxOtuXuImH3olWo7sjuk8NLOjQlGGWKPq9MOI/ctc+Gp uxX+t/WN9M/sXVFGFbp6ZwQX+OoICV/dgzsOVfj99JvthnMUiYMzk1KwY1Kvg/z/a4D0 OVmw== X-Gm-Message-State: AKS2vOwzCH3LEzU5LepQioxKOVlospqtwWU1G9y4TnT4718IOcXYEyLa 5ZzjpHOTkCXr+H9+ X-Received: by 10.28.59.212 with SMTP id i203mr2785178wma.18.1497517393857; Thu, 15 Jun 2017 02:03:13 -0700 (PDT) Received: from glumotte.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id w128sm2323069wmd.7.2017.06.15.02.03.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 15 Jun 2017 02:03:13 -0700 (PDT) Date: Thu, 15 Jun 2017 11:03:31 +0200 From: Olivier MATZ To: "Wu, Jingjing" Cc: "Xing, Beilei" , "Richardson, Bruce" , "Zhang, Helin" , "dev@dpdk.org" Message-ID: <20170615110331.3c8ca067@glumotte.dev.6wind.com> In-Reply-To: <9BB6961774997848B5B42BEC655768F810DA461C@SHSMSX103.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> <20170612114530.0eab4314@platinum> <9BB6961774997848B5B42BEC655768F810DA1FAE@SHSMSX103.ccr.corp.intel.com> <20170613102731.518aa083@glumotte.dev.6wind.com> <9BB6961774997848B5B42BEC655768F810DA461C@SHSMSX103.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: Thu, 15 Jun 2017 09:03:14 -0000 Hi, On Tue, 13 Jun 2017 14:14:43 +0000, "Wu, Jingjing" wrote: > > -----Original Message----- > > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > > Sent: Tuesday, June 13, 2017 4:28 PM > > To: Wu, Jingjing > > Cc: Xing, Beilei ; Richardson, Bruce ; > > Zhang, Helin ; dev@dpdk.org > > Subject: Re: [dpdk-dev] i40e: pci probe fails when using one bogus sfp > > > > Hi Jingjing, > > > > On Mon, 12 Jun 2017 16:23:47 +0000, "Wu, Jingjing" wrote: > > > HI, Olivier > > > > > > > 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? > > > > > > > Could your customer help to check what is the exactly error code is by > > > Checking the "hw->aq.asq_last_status" when eth_i40e_dev_init() fails. > > > > I'm afraid it won't be possible, since it's a random issue that is > > not reproducible. > > > > What do you think about adding a log in i40e_dev_sync_phy_type() to > > display the status value in case of failure? It would help for next > > times. I can submit a patch for that if you want. > > > Yes, It makes sense. Thanks for doing that. > > > > Yes, it seems better PHY init fails doesn't block PCI probe. Just compared with i40e > > > Kernel version, PHY init fails doesn't block CPI probe. And there is watchdog task to > > > Check the PHY status. But DPDK is polling mode, If PCI probe fails, PCI probe continues, > > > then application need poll PHY status to support SFP change. > > > > From what I understand, i40e_dev_sync_phy_type() was added > > to know the PHY capabilities, which useful for instance for devinfo(). > > Indeed, devinfo() can be call before the port is started, so > > we need to have get the PHY capabilities before starting the port. > > > > I've done a quick patch that: > > - keeps the call to i40e_dev_sync_phy_type() in pci probing but > > continue in case of failure > > - add another call to i40e_dev_sync_phy_type() in port start > > function > > > I think this workaround would not introduce issue if SFP is ready on NIC before Probe. > But I'm not sure if it can resolve the issue, because during probe, dozens of initialization work > Is ongoing. I think we need to verify it PHY init during start phase works or not. Maybe we > Need to do more than that? Not sure. After discussion with Helin, I moved the call to i40e_dev_sync_phy_type() in dev_configure(). I'm sending it as a reply to this mail. I see if I can get my patch tested by the customer. > > > I think it would solve the issue without impacting the result > > of the devinfo() function. What would you think of a patch like > > this? > > > > > And I also checked ixgbe driver, it seems phy init is done at probe time. > > > In my opinion, dev_start and dev_stop is meaning ready for receiving and transmitting > > > packets, it may not be suitable to put it in the start/stop phase. > > > > I'm wondering: what would/should occur if the SFP is unplugged and > > replugged while the port is running? > > > > I suppose we don't have any PCI notification when unplugging/plugging > > the SFP, so I'm not sure we should have this check at the PCI level, > > because the application does not know if the bus has to be probed again. > > > We can consider about unplugging/plugging as link event in DPDK. Now we > have LSC or user can polling link status. Maybe that is a way to go. Yes, I agree. Thanks for the confirmation.