>>> >>> The hw->allow_unsupported_sfp is used too late in >>> https://git.dpdk.org/next/dpdk-next-net-intel/tree/drivers/net/ixgbe/b >>> ase/ixgbe_phy.c#n1530 And if we've already got out earlier in >>> https://git.dpdk.org/next/dpdk-next-net-intel/tree/drivers/net/ixgbe/b >>> ase/ixgbe_phy.c#n1507 >> >> As I can read the code that check is for 1G SFPs. >> So if you getting out here, then comp_codes_10g == 0 here, and it means >> that given SFP is not recognized as 10G one. >> I wonder why that happens? >> >> As I can see comp_codes_10g should be initialized at line 1314: >> status = hw->phy.ops.read_i2c_eeprom(hw, >> >> IXGBE_SFF_10GBE_COMP_CODES, >> &comp_codes_10g); >> > > The samples I have (from 2 vendors) read 0 from the eeprom > IXGBE_SFF_10GBE_COMP_CODES offset > > SFF-8472 spec [https://members.snia.org/document/dl/25916] doesn't define a > code value for 10GBASE-T > TABLE 5-3 TRANSCEIVER COMPLIANCE CODES > 10G Ethernet Compliance Codes > 3 7 10G Base-ER > 3 6 10G Base-LRM > 3 5 10G Base-LR > 3 4 10G Base-SR > Infiniband Compliance Codes > 3 3 1X SX > 3 2 1X LX > 3 1 1X Copper Active > 3 0 1X Copper Active > Seems they are right not to set any code from above, no? > > Do you know any 10GBASE-T SFPs that does work? > Any idea what does it return for this field? >
I can confirm we saw the same issues using Aquantia SFP+ Copper modules with 550 MAC. Indeed there is no separate id for Base-T. ixgbe logic both in kernel and dpdk discards such modules. Regards, Igor
