RE: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI

["Zhang, Qi Z" <qi.z.zhang@intel.com>]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, May 24, 2022 11:55 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Daly, Jeff <jeffd@silicom-usa.com>; dev@dpdk.org; Wang, Haiyue
> <haiyue.wang@intel.com>; ferruh.yigit@amd.com;
> andrew.rybchenko@oktetlabs.ru; Richardson, Bruce
> <bruce.richardson@intel.com>; Mcnamara, John
> <john.mcnamara@intel.com>
> Subject: Re: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link
> partners for X550 SFI
> 
> 24/05/2022 15:42, Zhang, Qi Z:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 18/05/2022 02:03, Zhang, Qi Z:
> > > > From: Jeff Daly <jeffd@silicom-usa.com>
> > > > >
> > > > > Some SFP link partners exhibit a disinclination to autonegotiate
> > > > > with X550 configured in SFI mode.  This patch enables a manual
> > > > > AN-37 restart to work around the problem.
> > > >
> > > > This fix for some specific hardware in base code, unfortunately
> > > > Intel DPDK team don't have the device and the knowledge to approve
> > > > this,
> > >
> > > That's why the work is collaborative.
> > > You should get and trust knowledge from partners.
> > > The only concerns of a maintainer should be:
> > > 	- good feature design
> > > 	- good code quality
> >
> > These are the questions we can't answer, we don't understand the
> > design, what is " change mode enforcement rules to hybrid " means,
> > what is manual AN-37 here and what those numbers in the patch means.
> 
> So these are the basic questions you should ask to be made clear in the patch.
> That's the same for everybody: we must understand the reason and the
> intent of any change.
> 
> > Of cause we trust knowledge from our partners, but anyway this is an
> > Intel product,
> 
> The DPDK driver is not an Intel product.
> This a community effort where anyone should be able to participate.

I'm taking about the hardware not the driver.

> 
> > only Intel have the right to authenticate this.
> 
> What do you mean by "authenticate"?
> 
> > unfortunately none of the active ixgbe DPDK maintainers and I have the
> > knowledge Meanwhile if this is an issue on DPDK, it could also be an
> > issue on kernel driver that's why we suggest to submit to Linux
> > community first where will be right people to answer above questions.
> 
> Why Linux community is more able to review than DPDK, or FreeBSD, or
> Windows, or any other community?

Of cause DPDK could be able to,  if the people have the corresponding knowledge that works on it
I would say on this very specific domain, DPDK community has the gap that depends on Intel,
Nothing else, we just try to provide workable suggestion based on current situation, meanwhile we will escalate.  

> 
> > > 	- no regression in known cases
> >
> > > > the base code is delivered by our kernel software team, I will
> > > > suggest you can send this to the kernel community to get the right
> > > > expert to review.
> > >
> > > Which kind of expert do you imagine to review?
> > > Intel team or Silicom people who are pushing these improvements?
> >
> > > There is another problem with asking Linux kernel change first:
> > > the patch will land in GPL code, bringing difficulties to move in
> > > BSD-licensed base code.
> >
> > Only if the author agree to share the copy right to Intel, so Intel is
> > able to re-license it to BSD as same as other base code.
> 
> Yes we should be able to grant such copyright in the commit message.
> 
> > > I suggest we make this process more flexible:
> > > 	1/ a contributor sends a patch for DPDK base code
> > > 	   with an explicit grant for backporting in any license.
> > > 	2/ Intel checks that there is no DPDK regression
> > > 	3/ patch is merged in DPDK
> > > 	4/ Intel merges it in the internal base code
> > > 	5/ Linux kernel team can backport the fix to Linux
> > > 	6/ Any other OS can backport the fix in its driver
> >
> > Right now, our base code in kernel is GPL license only, code with
> > BSD-3-clause can't be distrusted without change our license strategy,
> > so it's the same effort if someone want to backport DPDK changes to
> > kernel (shared the copy right to Intel)
> >
> > but I like your suggestion (if I understand correctly), have a dual
> > licenses in kernel base code make things smoothly to backport from
> > DPDK to kernel, I will feedback this.
> >
> > > Let's make the DPDK process open for everybody.
> >
> > For sure, we should.
> 
>