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

["Stillwell Jr, Paul M" <paul.m.stillwell.jr@intel.com>]

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Igor Russkikh
> Sent: Monday, May 6, 2019 4:22 AM
> To: Ido Goshen <Ido@cgstowernetworks.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: 10GBASE-T SFP+ copper support
> 
> 
> >>>
> >>> 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

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.

Paul