* [dpdk-users] DPDK16.11.2 LTS: i40e PMD fails to start X710 port @ 2017-07-19 13:49 Dumitru Ceara 2017-08-01 9:55 ` Dumitru Ceara 0 siblings, 1 reply; 3+ messages in thread From: Dumitru Ceara @ 2017-07-19 13:49 UTC (permalink / raw) To: users; +Cc: Wu, Jingjing, Xing, Beilei 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dpdk-users] DPDK16.11.2 LTS: i40e PMD fails to start X710 port 2017-07-19 13:49 [dpdk-users] DPDK16.11.2 LTS: i40e PMD fails to start X710 port Dumitru Ceara @ 2017-08-01 9:55 ` Dumitru Ceara 2017-09-07 7:20 ` [dpdk-users] [dpdk-dev] " Li, Xiaoyun 0 siblings, 1 reply; 3+ messages in thread From: Dumitru Ceara @ 2017-08-01 9:55 UTC (permalink / raw) To: dev; +Cc: Wu, Jingjing, Xing, Beilei, users 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@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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dpdk-users] [dpdk-dev] DPDK16.11.2 LTS: i40e PMD fails to start X710 port 2017-08-01 9:55 ` Dumitru Ceara @ 2017-09-07 7:20 ` Li, Xiaoyun 0 siblings, 0 replies; 3+ messages in thread From: Li, Xiaoyun @ 2017-09-07 7:20 UTC (permalink / raw) To: Dumitru Ceara, dev; +Cc: Wu, Jingjing, Xing, Beilei, users, Zhang, Helin 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@dpdk.org] On Behalf Of Dumitru Ceara Sent: Tuesday, August 1, 2017 17:56 To: dev@dpdk.org Cc: Wu, Jingjing <jingjing.wu@intel.com>; Xing, Beilei <beilei.xing@intel.com>; users@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@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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-09-07 7:20 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-07-19 13:49 [dpdk-users] DPDK16.11.2 LTS: i40e PMD fails to start X710 port Dumitru Ceara 2017-08-01 9:55 ` Dumitru Ceara 2017-09-07 7:20 ` [dpdk-users] [dpdk-dev] " Li, Xiaoyun
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).