> From: Wang, Haiyue [mailto:haiyue.w...@intel.com] > Sent: Wednesday, 22 December 2021 17.03 > > > -----Original Message----- > > From: Morten Brørup <m...@smartsharesystems.com> > > Sent: Wednesday, December 22, 2021 18:44 > > > > > From: Wang, Haiyue [mailto:haiyue.w...@intel.com] > > > Sent: Wednesday, 22 December 2021 02.24 > > > > > > > -----Original Message----- > > > > From: Morten Brørup <m...@smartsharesystems.com> > > > > Sent: Tuesday, December 21, 2021 16:58 > > > > > > > > > From: Wang, Haiyue [mailto:haiyue.w...@intel.com] > > > > > Sent: Tuesday, 21 December 2021 02.15 > > > > > > > > > > > -----Original Message----- > > > > > > From: Stephen Douthit <steph...@silicom-usa.com> > > > > > > Sent: Tuesday, December 21, 2021 05:33 > > > > > > > > > > > > On 12/20/21 02:53, Wang, Haiyue wrote: > > > > > > >> -----Original Message----- > > > > > > >> From: Stephen Douthit <steph...@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: sta...@dpdk.org > > > > > > >> > > > > > > >> Signed-off-by: Stephen Douthit <steph...@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. :-)
