> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Wednesday, May 25, 2022 3:56 PM
> To: Zhang, Qi Z <qi.z.zh...@intel.com>
> Cc: Daly, Jeff <je...@silicom-usa.com>; dev@dpdk.org; Wang, Haiyue
> <haiyue.w...@intel.com>; ferruh.yi...@amd.com;
> andrew.rybche...@oktetlabs.ru; Richardson, Bruce
> <bruce.richard...@intel.com>; Mcnamara, John
> <john.mcnam...@intel.com>
> Subject: Re: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link
> partners for X550 SFI
>
> 25/05/2022 02:11, Zhang, Qi Z:
> > From: Thomas Monjalon <tho...@monjalon.net>
> > > 24/05/2022 15:42, Zhang, Qi Z:
> > > > From: Thomas Monjalon <tho...@monjalon.net>
> > > > > 18/05/2022 02:03, Zhang, Qi Z:
> > > > > > From: Jeff Daly <je...@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.
>
> The SFP is not an Intel product.
I'm talking about supported ixgbe NICs , that's patch will impact.
https://doc.dpdk.org/guides/nics/ixgbe.html
>
> > > > only Intel have the right to authenticate this.
> > >
> > > What do you mean by "authenticate"?
>
> You forgot this question.
> What do you mean by "authenticate"?
I mean a hardware vendor to judge if a configure is correct or not on its own
product.
Btw, I may not express this clearly in previous, I would say "responsibility"
but not the "right"
>
> > > > 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.
>
> You can get the knowledge by asking the right questions.
>
> > > > > - 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.
>
>
