[dpdk-dev] [PATCH] net/ixgbe: 10GBASE-T SFP+ copper support

[Igor Russkikh]

>>>
>>> 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