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