From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id DAB94A054F; Wed, 25 May 2022 09:56:08 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 809A2400EF; Wed, 25 May 2022 09:56:08 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 299DC400D6 for ; Wed, 25 May 2022 09:56:06 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BEA5D5C0229; Wed, 25 May 2022 03:56:03 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 25 May 2022 03:56:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1653465363; x= 1653551763; bh=Hzlfuyi6Zq2szVb/szMyZQrX/QVmKi0cE86PgYjmCbE=; b=Z EsG8ZUb019phr7jtHGpJAakFpaS5tUb/5G2aW5L0ICN7SwLYopIA6n8wSSmri58R m3WWcfvzwhY8KyRMRn85z4DkbwI9d6F7fzQjESip328lh6Dk728u8dOPF4d40F9V iYJMZo2eEMeYL42mSXKxlRVC9gyEGvsWzS5bwnq6lrfspQYGyskDoDer69YlnxHM A5T3j1Pmqqi9kFlOZ7h67X493xlJoAZZgPzo42P8f99VyKed5GP4nY04piXLEX6J CpM0o48UCn7aowi6y3FlvPFpfwISvDY1hUXQ9F+clR75fNA+PiRJ9OeUOPUU9XHj BlRNEOoXcrSl/cCHEZxkA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1653465363; x= 1653551763; bh=Hzlfuyi6Zq2szVb/szMyZQrX/QVmKi0cE86PgYjmCbE=; b=D AMEcB98YlT9LttCB5AWEcO64gE/75dGjTxLZworA7xLiBVxXaHHnuKxCQxnXk5l5 tk2Q3rK2Yvgx1X+erUZfZZ1Fs+YmAJt02qdzz7PLlQ7/fdnbWwY1t1WCmpzrIZIO XQbFyoSmkei/fxV3/hq88I/Gg0zaoPTCni7mc06DsOgvF3QU2zLR+bwmNeKfbYlu Bk1Q3ZhhUpnVpJwVTk2SDPsVR8Wbq01tZIj5sOJAoRy1EMUxuO3YNdTQxKgXTcik cWQGVa7r5phexCmUs4GzZxbiw5Ui9WeyzGmA5TPZDQkrkXgQAVMd2nmryxl+GDfa OZNmPSGw317zVIgO24BXQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrjeeggdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 25 May 2022 03:56:01 -0400 (EDT) From: Thomas Monjalon To: "Zhang, Qi Z" Cc: "Daly, Jeff" , "dev@dpdk.org" , "Wang, Haiyue" , "ferruh.yigit@amd.com" , "andrew.rybchenko@oktetlabs.ru" , "Richardson, Bruce" , "Mcnamara, John" Subject: Re: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI Date: Wed, 25 May 2022 09:55:52 +0200 Message-ID: <3526909.qqrk5fENW1@thomas> In-Reply-To: References: <20220316181544.7251-1-jeffd@silicom-usa.com> <4594196.1oUyQt6lIG@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 25/05/2022 02:11, Zhang, Qi Z: > From: Thomas Monjalon > > 24/05/2022 15:42, Zhang, Qi Z: > > > From: Thomas Monjalon > > > > 18/05/2022 02:03, Zhang, Qi Z: > > > > > From: Jeff Daly > > > > > > > > > > > > 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.