[dpdk-dev] i40e_aq_get_phy_capabilities() fails when using SFP+ with no link

Christos Ricudis ricudis.christos at gmail.com
Tue Jan 10 13:32:26 CET 2017


Using a X710 based 4-port 4x10Gbit NIC, I have came across the following issue on the i40e PMD: 

When an optical SFP+ (Finisar FTLX8571D3BCL) is used with no active link partner on the other end of the link (or fiber completely disconnected from the SFP+), i40e_aq_get_phy_capabilities() (called by i40e_dev_sync_phy_type() on port initialization), fails with a 0x05 return value (EIO) on the AQ response structure. The struct i40e_aq_get_phy_abilities_resp buffer passed to the Get Phy Abilities command is unmodified upon return. 

This prevents DPDK 16.11 from initializing the port, and ultimately fails with the following error: 

PMD: eth_i40e_dev_init(): Failed to sync phy type: -95

The change introducing this issue was http://dpdk.org/ml/archives/dev/2016-September/047663.html

Reading the X710 datasheet, I notice that no specific mention is given on the meaning of EIO as a response to Get PHY Abilities command (opcode 0x0600), whereas in most other commands, an explicit mention of the meaning of the possible error status responses is given. 

This behaviour is the same across the following NVM releases: 

FW 4.33 API 1.2 NVM 04.04.02 eetrack 800018a6
FW 4.40 API 1.4 NVM 04.05.03 eetrack 80001cd8
FW 5.0 API 1.5 NVM 05.00.04 eetrack 800024da

I will try to get around the issue by falling back to PHY capabilities detection using the device ID in the case i40e_aq_get_phy_capabilities() fails, but conceptually the capabilities of the PHY should not be dependent on whether PHY detects an active link or not. 

I’d be happy to do more testing on this issue per your recommendations. 

Moreover, while trying to debug this issue, I managed to get both 3 NIC adapters on my test system on a state where the PHY has apparently died - no link indication at all on any ports. A reboot solved this, and I am now trying to replicate this behaviour under more controlled conditions. 

Best regards, 
Christos Ricudis.

More information about the dev mailing list