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

[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.

> 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?

> > 	- 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.