[dpdk-dev] [PATCH] net/ixgbe: 10GBASE-T SFP+ copper support
Igor Russkikh
Igor.Russkikh at aquantia.com
Mon May 6 13:22:27 CEST 2019
>>>
>>> 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
More information about the dev
mailing list