> -----Original Message----- > From: Stillwell Jr, Paul M <paul.m.stillwell...@intel.com> > Sent: Wednesday, May 8, 2019 1:46 AM > To: Igor Russkikh <igor.russk...@aquantia.com>; Ido Goshen > <i...@cgstowernetworks.com>; Ananyev, Konstantin > <konstantin.anan...@intel.com>; Lu, Wenzhuo <wenzhuo...@intel.com> > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH] net/ixgbe: 10GBASE-T SFP+ copper support > > > > -----Original Message----- > > From: dev <dev-boun...@dpdk.org> On Behalf Of Igor Russkikh > > Sent: Monday, May 6, 2019 4:22 AM > > To: Ido Goshen <i...@cgstowernetworks.com>; Ananyev, Konstantin > > <konstantin.anan...@intel.com>; Lu, Wenzhuo <wenzhuo...@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
