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 0C77BA0540; Tue, 24 May 2022 17:54:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B043C400EF; Tue, 24 May 2022 17:54:55 +0200 (CEST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id CEEE7400D6 for ; Tue, 24 May 2022 17:54:53 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id D04FB3200909; Tue, 24 May 2022 11:54:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 24 May 2022 11:54:51 -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=1653407690; x= 1653494090; bh=GL61qZ6Z62a70vSOBAb1j/qkSlsnFKcnHNsie+mF4wM=; b=c qEx6ZXpd4t5gqn0fXhaBMdNlug3nhhwSQ+gpmmn8w+KzfK/d4Yjhb1Jlt6pSkMIn rVGnG0dDTmDjcm9MerLA5UkEbaEhzcs169lFAykg+/xAa+/fy3Jiv5kfzcvZkNci 1DKe6e2KbquFabWh0988+hgSLpkqUbZVVpFLhjNG3Ona8evNDoG56ZC+QeF0Nlx9 chZvL8XpK/rzP4ETy6+bX607qUY9si7KufxmzdA89s8JDTxT0xehtcvFLusVHfSB p77QhMXLZC/2CteeseqADLKTRdGutUQkM6szZ9IbS/0U4CQILqsS8SIIEZltx/Ne RSMAK6m9aRgYnSJQ5nzig== 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=1653407690; x= 1653494090; bh=GL61qZ6Z62a70vSOBAb1j/qkSlsnFKcnHNsie+mF4wM=; b=t qiDnUC6oeYBEM0icXIFURHUwXsPVuoD0MpPWNL1yXNOACLpkUUlfa3CIw4pkOkS2 G80w6rYsGH1xxTjPOHvfea/WSboVtspY79G/c994prE05DAc9PcPwboITTLnTcKA YQBT2WGzRCBzToVfR9keG5mgVrz4sZXhK+4w9Fkold2R0Y5ENca84ASrSaXZwk7H LdWVcburEdy59GTQdMPXgOWofdG7WKpkSvriHhBYwg1fxIzzOUFIhM9YeFP7AN/r B29kM24SotjiwFvI/cIi9QESOz4faJ7hfpYaxl8Jn68S2jtpO1n+PxeIptEoLRoA DyXwys04ZwD3pr5h02aJw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrjeefgdelhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieek gfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 24 May 2022 11:54:47 -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" , john.mcnamara@intel.com Subject: Re: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI Date: Tue, 24 May 2022 17:54:40 +0200 Message-ID: <4594196.1oUyQt6lIG@thomas> In-Reply-To: References: <20220316181544.7251-1-jeffd@silicom-usa.com> <11811318.eQLIkvUDd3@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 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. > 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.