> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Tuesday, May 24, 2022 6:43 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>
> Subject: Re: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link
> partners for X550 SFI
>
> 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.
Of cause we trust knowledge from our partners, but anyway this is an Intel
product, only Intel have the right to authenticate this. 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.
> - 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.
>
> 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.
>
