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

[Wang, Haiyue]

> -----Original Message-----
> From: Morten Brørup <mb at smartsharesystems.com>
> Sent: Wednesday, December 22, 2021 18:44
> To: Wang, Haiyue <haiyue.wang at intel.com>; stephend at silicom-usa.com; Lu, Wenzhuo <wenzhuo.lu at intel.com>;
> Zhang, Helin <helin.zhang at intel.com>; Zhang, Qi Z <qi.z.zhang at intel.com>
> Cc: dev at dpdk.org; Wang, Wen <wenw at silicom-usa.com>; stable at dpdk.org
> Subject: RE: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
> 
> > From: Wang, Haiyue [mailto:haiyue.wang at intel.com]
> > Sent: Wednesday, 22 December 2021 02.24
> >
> > > -----Original Message-----
> > > From: Morten Brørup <mb at smartsharesystems.com>
> > > Sent: Tuesday, December 21, 2021 16:58
> > >
> > > > From: Wang, Haiyue [mailto:haiyue.wang at intel.com]
> > > > Sent: Tuesday, 21 December 2021 02.15
> > > >
> > > > > -----Original Message-----
> > > > > From: Stephen Douthit <stephend at 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 at 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 at dpdk.org
> > > > > >>
> > > > > >> Signed-off-by: Stephen Douthit <stephend at 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. ;-)

> 
> 
> Med venlig hilsen / kind regards
> 
> Morten Brørup
> CTO
> 
> 
> SmartShare Systems A/S
> Tonsbakken 16-18
> DK-2740 Skovlunde
> Denmark
> 
> Office      +45 70 20 00 93
> Direct      +45 89 93 50 22
> Mobile      +45 25 40 82 12
> 
> mb at smartsharesystems.com
> www.smartsharesystems.com