From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f182.google.com (mail-wr0-f182.google.com [209.85.128.182]) by dpdk.org (Postfix) with ESMTP id 5132A568A for ; Tue, 13 Jun 2017 10:27:17 +0200 (CEST) Received: by mail-wr0-f182.google.com with SMTP id g76so127022126wrd.1 for ; Tue, 13 Jun 2017 01:27:17 -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=EkulCJLy2BEmFx4IO1C8KoZ3hjxlDbjA6V4qKWru6Mc=; b=VSeYAv0W1XNLiTcugd8Ygt4COc+KsZxY+T63kt/RC0e14mDIHZO2B0QvrLFc7Jcwau lSb4FV4frn+LSpzd5RdhyF/r0dWSsaTs4NdTd1ZO9LRFR1vlCTlKFi8fCmAhxT5ulRrS VUU3hmpgtb1MkBb2bOHm5pq4CxaspwdrtVjlS2UBjR3my8nTRwGKQtVExJyumAQBv3nH gdMDcO0mK6syKhKl5HPAy8Rcu45IydQtzNdh8OcOt7wCehXianWn+fPWS0hoHGotkkci Ir3d/os0zH4j8L7Q0Bw0dY6XPsfs99ja7AFyFbmFoiSX5zWWM59nqotb5kHEN52NgtRe lN/Q== 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=EkulCJLy2BEmFx4IO1C8KoZ3hjxlDbjA6V4qKWru6Mc=; b=ZEk/EYE0DpqmS6tN/Tba4qzEBUkOzF+msAUHA9pZQYZRzmJ5bnyRT/QUADz3/tBa68 iq9aoVFRIiUJkpm0OGt26b9UpCEP4+quvWm81qXwiYoUUnb0Z5fzZhHHrVvGAenrg/vW Q078qgEr2UMmGhQZ0TyvZPuFv07QH8C9g/Vib6qldvfZn9LRrTP5VgTbaO+oPwgjTTkH 0jA4jPcP/5hxB8tS+ZsY3L2UL5Z7TlLv0MLZwrCM1w65fMhuy1TPyy7psmBi//WFTWLQ D620eV+tSW1TCdSf+rT84Aw1V31ZNjseUBn4RfJBiT+0uyZ1LzRlQvmODbk1wRjKXDDL JK0Q== X-Gm-Message-State: AKS2vOyTYS8TPPfsJs3PMPkaEaKmIWR9kfboF6pk3H0rzDAji7r9DFsK dFwGb/UL6lhOZMQ/ X-Received: by 10.28.74.80 with SMTP id x77mr1814761wma.81.1497342433355; Tue, 13 Jun 2017 01:27: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 v13sm3161223wmd.5.2017.06.13.01.27.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 13 Jun 2017 01:27:13 -0700 (PDT) Date: Tue, 13 Jun 2017 10:27:31 +0200 From: Olivier MATZ To: "Wu, Jingjing" Cc: "Xing, Beilei" , "Richardson, Bruce" , "Zhang, Helin" , "dev@dpdk.org" Message-ID: <20170613102731.518aa083@glumotte.dev.6wind.com> In-Reply-To: <9BB6961774997848B5B42BEC655768F810DA1FAE@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> 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: quoted-printable 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: Tue, 13 Jun 2017 08:27:17 -0000 Hi Jingjing, On Mon, 12 Jun 2017 16:23:47 +0000, "Wu, Jingjing" = wrote: > HI, Olivier >=20 > > Thank you for your quick answer. > >=20 > > Yes, the pci probing continues for the other ports even if one port > > failed (since v17.05, commit 10f6c93cea). > >=20 > > 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? > > =20 > 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 seems better PHY init fails doesn't block PCI probe. Just compare= d with i40e > Kernel version, PHY init fails doesn't block CPI probe. And there is watc= hdog task to > Check the PHY status. But DPDK is polling mode, If PCI probe fails, PCI p= robe continues, > then application need poll PHY status to support SFP change. =46rom 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 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. Thanks Olivier