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

[Ido Goshen <Ido@cgstowernetworks.com>]

> -----Original Message-----
> From: Stillwell Jr, Paul M <paul.m.stillwell.jr@intel.com>
> Sent: Wednesday, May 8, 2019 1:46 AM
> To: Igor Russkikh <Igor.Russkikh@aquantia.com>; 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
> 
> 
> > -----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/ixg
> > >>> be
> > >>> /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/ixg
> > >>> be
> > >>> /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.

Doesn't it contradict https://git.dpdk.org/next/dpdk-next-net-intel/commit/?id=aa1a048729808c4c1797649b3863b00c661e5ee4?
Which say "No need to restrict usage of non Intel SFP."

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