>>> 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 > > The issue is really that there are bad modules out there and Intel only > supports the ones that have been tested in our labs and verified to > consistently work. We get too many support tickets for modules that don't > work and so the best thing for us to do is to test some set of modules, > verify they work, mark them as supported, and move on. > > Feel free to apply this patch to your local repo and move on, but we can't > support these modules in the code and will not accept a patch to support them.
That's reasonable, but then all the rationality of `hw->allow_unsupported_sfp` goes away, as you do not allow the particular type (copper) of unsupported sfps. Regards, Igor
