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

[Thomas Monjalon <thomas@monjalon.net>]

25/05/2022 02:11, Zhang, Qi Z:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 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.

The SFP is not an Intel product.

> > > only Intel have the right to authenticate this.
> > 
> > What do you mean by "authenticate"?

You forgot this question.
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.

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.