[dpdk-dev] [dpdk-users] DPDK16.11.2 LTS: i40e PMD fails to start X710 port

Li, Xiaoyun xiaoyun.li at intel.com
Thu Sep 7 09:20:38 CEST 2017


Hi

I think DPDK17.08 has fixed this issue.
There is a patch in 17.08 which would introduced a delay in i40e_dev_sync_phy_type if getting wrong status.


Best Regards,
Xiaoyun Li




-----Original Message-----
From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Dumitru Ceara
Sent: Tuesday, August 1, 2017 17:56
To: dev at dpdk.org
Cc: Wu, Jingjing <jingjing.wu at intel.com>; Xing, Beilei <beilei.xing at intel.com>; users at dpdk.org
Subject: Re: [dpdk-dev] [dpdk-users] DPDK16.11.2 LTS: i40e PMD fails to start X710 port

Hi all,

I'm reposting the following bug report on the dev mailing list. I was wondering if this is a known issue or not.

In our application code, the only way to overcome the problem is to introduce a delay after each rte_eth_dev_stop/start call when using
X710 cards. However, this seems like a hacky temporary fix as it increases the "start-up" time unnecessarily.

Thanks,
Dumitru

On Wed, Jul 19, 2017 at 3:49 PM, Dumitru Ceara <dumitru.ceara at gmail.com> wrote:
> Hi all,
>
> With DPDK 16.11.2 LTS we see "intermittent" errors when trying to 
> start an X710 interface (latest firmware - FW 5.05).
>
> Due to the fact that the i40e PMD requires the port to be stopped when 
> setting MTU we use the following sequence in our code:
> 1. rte_eth_dev_ stop
> 2. rte_eth_dev_set_mtu
> 3. rte_eth_dev_start
>
> If rte_eth_dev_start is called shortly after stop (as is in our case), 
> the i40e_phy_conf_link sometimes fails and returns -ENOTSUP. This 
> happens because i40e_aq_get_phy_capabilities returns status 
> I40E_ERR_UNKNOWN_PHY. I double checked and the transceivers we use are 
> Intel FTLX8571D3BCV-IT.
>
> Moreover, if we introduce a delay (e.g., 10 seconds) after 
> rte_eth_dev_stop then rte_eth_dev_start works fine.
>
> In order to eliminate potential issues with our code I tried to 
> replicate with test-pmd with "disable-link-check" in order to avoid 
> the delay introduced by link state checking:
>
> # $RTE_SDK/tools/dpdk-devbind.py -s
>
> Network devices using DPDK-compatible driver 
> ============================================
> 0000:82:00.0 'Ethernet Controller X710 for 10GbE SFP+' drv=igb_uio 
> unused=
> 0000:82:00.1 'Ethernet Controller X710 for 10GbE SFP+' drv=igb_uio 
> unused=
>
> # $RTE_SDK/x86_64-native-linuxapp-gcc/build/app/test-pmd/testpmd -w
> 0000:82:00.0 -w 0000:82:00.1 -- --disable-link-check -i
> EAL: Detected 32 lcore(s)
> EAL: Probing VFIO support...
> EAL: PCI device 0000:82:00.0 on NUMA socket 1
> EAL:   probe driver: 8086:1572 net_i40e
> PMD: eth_i40e_dev_init(): FW 5.0 API 1.5 NVM 05.00.05 eetrack 8000289d
> EAL: PCI device 0000:82:00.1 on NUMA socket 1
> EAL:   probe driver: 8086:1572 net_i40e
> PMD: eth_i40e_dev_init(): FW 5.0 API 1.5 NVM 05.00.05 eetrack 8000289d 
> Interactive-mode selected
> USER1: create a new mbuf pool <mbuf_pool_socket_0>: n=395456, 
> size=2176, socket=0 Configuring Port 0 (socket 0) Port 0: 
> 3C:FD:FE:9C:79:F0 Configuring Port 1 (socket 0) Port 1: 
> 3C:FD:FE:9C:79:F1 Done
> testpmd> port stop 1
> Stopping ports...
> Done
> testpmd> port start 1
> Port 1: 3C:FD:FE:9C:79:F1
> Done
> testpmd> port stop 1
> Stopping ports...
> Done
> testpmd> port start 1
> Fail to start port 1
> Please stop the ports first    <<<<<<< Here we fail to stop port 1
> Done
>
> I saw there were some more reports of similar I40E_ERR_UNKNOWN_PHY 
> issues but I'm not sure if they were related to the device stop/start 
> sequence. Is this a known limitation of the driver/firmware? Is the 
> application supposed to deal with this specific behavior of the X710?
> If so, how would an application detect that the rte_eth_dev_stop 
> operation has completed? Or are we missing some hardware specific 
> initialization?
>
> Thanks,
> Dumitru



--
Dumitru Ceara


More information about the dev mailing list