RE: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Wang, Haiyue [mailto:haiyue.wang@intel.com]
> Sent: Wednesday, 22 December 2021 17.03
> 
> > -----Original Message-----
> > From: Morten Brørup <mb@smartsharesystems.com>
> > Sent: Wednesday, December 22, 2021 18:44
> >
> > > From: Wang, Haiyue [mailto:haiyue.wang@intel.com]
> > > Sent: Wednesday, 22 December 2021 02.24
> > >
> > > > -----Original Message-----
> > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > Sent: Tuesday, December 21, 2021 16:58
> > > >
> > > > > From: Wang, Haiyue [mailto:haiyue.wang@intel.com]
> > > > > Sent: Tuesday, 21 December 2021 02.15
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Stephen Douthit <stephend@silicom-usa.com>
> > > > > > Sent: Tuesday, December 21, 2021 05:33
> > > > > >
> > > > > > On 12/20/21 02:53, Wang, Haiyue wrote:
> > > > > > >> -----Original Message-----
> > > > > > >> From: Stephen Douthit <stephend@silicom-usa.com>
> > > > > > >> Sent: Tuesday, December 7, 2021 06:19
> > > > > > >>
> > > > > > >> Make sure an SFP is really a SFF-8472 device that supports
> the
> > > > > optional
> > > > > > >> soft rate select feature before just blindly poking those
> I2C
> > > > > registers.
> > > > > > >>
> > > > > > >> Skip all I2C traffic if we know there's no SFP.
> > > > > > >>
> > > > > > >> Fixes: f3430431aba ("ixgbe/base: add SFP+ dual-speed
> support")
> > > > > > >> Cc: stable@dpdk.org
> > > > > > >>
> > > > > > >> Signed-off-by: Stephen Douthit <stephend@silicom-usa.com>
> > > > > > >> ---
> > > > > > >
> > >
> > >
> > > > >
> > > > > Normally, DPDK keeps sync with this kind of release.
> > > > >
> > > >
> > > > Working with the Linux kernel mainline drivers is good advice.
> > > >
> > > > The official Intel Linux drivers seem to be ages behind the
> Kernel
> > > mainline, and they don't fully
> > >
> > > No, the "ixgbe" drivers is updated on "7/8/2021".
> > >
> > > https://www.intel.com/content/www/us/en/download/14302/14687/intel-
> > > network-adapter-driver-for-pcie-intel-10-gigabit-ethernet-network-
> > > connections-under-linux.html
> >
> > So you can imagine my surprise that they didn't work on the C3338 SoC
> launched by Intel in Q1'17. The
> > web page says that the drivers supports kernel versions 2.6.18 to
> 5.12, so we expected them to work
> > with kernel 3.19. Perhaps they haven't been tested with the C3338
> SoC. Also, the test section on the
> > web page only mentions 64 bit distributions, so perhaps they haven't
> been tested with a 32 bit kernel.
> > There is no test report available, so I can only speculate.
> >
> > I am sorry if I came off as badmouthing the Intel out-of-tree driver.
> I was only trying to convey to
> > the good folks at Silicom that kernel.org is a better source of
> inspiration than the Intel out-of-tree
> > driver, which is not as up-to-date as the kernel.org driver, and thus
> not the optimal source of
> > inspiration for driver development. The out-of-tree drivers serve a
> different purpose, where they are
> > extremely valuable: In normal production environments where it is not
> an option to compile and deploy
> > a kernel from scratch.
> >
> 
> > >
> > > > support the C3000 NICs, so don’t waste any time there! We
> recently
> > > tried using the official Intel
> > > > Linux drivers for a C3338 based project (using Kernel 3.19 in 32
> bit
> > > mode with x2APIC disabled), and
> > > > they didn't work at all. We ended up backporting the necessary
> > > changes from the kernel mainline
> > > > instead.
> > >
> > > From Steve's response:
> > >      ME: "I guess this is just in C3000 reference board SDK ?"
> > >      Steve: "It's the board covered by Intel Doc # 574437."
> > >
> > > I check the doc "Last Updated: 11/07/2018".... It should be some
> kind
> > > of customer release, that's why
> > > they are not in the official *open source* Linux driver, so keep
> your
> > > patch set as private.
> >
> > I didn't mention it explicitly, but I'm not involved with Silicom,
> and was not referring to their
> > hardware. The hardware board we had problems with is currently in
> volume production at a major ODM.
> > But I guess that it is usually being deployed with a 64 bit kernel,
> as opposed to the 32 bit kernel we
> > were using.
> 
> I understood, but we need to follow the open source vs customer release
> policy,
> so not everything is upstream.
> 
> The ixgbe (especially in base directory) code is so stable, so in other
> words,
> this patch set can be rebased easily. ;-)
> 
> If the patch is about ixgbe ethdev part (vs kernel netdev), it will be
> welcomed,
> since our team mainly work on this (And the base code is mainly
> developed by the
> kernel team, that's why I recommend to send it to
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan).
> 
> Hope this will make things clear. ;-)

ACK. :-)