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 978EFA050D; Thu, 14 Apr 2022 17:43:08 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 774A540694; Thu, 14 Apr 2022 17:43:08 +0200 (CEST) Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by mails.dpdk.org (Postfix) with ESMTP id 1E48E40687 for ; Thu, 14 Apr 2022 17:43:07 +0200 (CEST) Received: by mail-pj1-f52.google.com with SMTP id md20-20020a17090b23d400b001cb70ef790dso9626530pjb.5 for ; Thu, 14 Apr 2022 08:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=edDTrhUtEQP1Jk6IJ37Gd5v2fus9tEAAWYNcz4Uh5bc=; b=n4YFRMwu1Sm8RFXp9u/5nAI+aHW3R9AB4xMTIOXbH4TQJ9sFGdk7k24IzaeKswJHzE +ptU4GUQrPQmE6I497uQAFDLU0LmwezffvCP7tq1LmLBTBB1Vwa5v+zy1kTA3GlkRVV7 2hTV8pJ5mU7L3g42J9BQm7SK/9tv1X9ULWoqZsooSYuJ23GizO6YESEP04BLw5lyBXyX PSgIUMCvu7TBa39Mg16cfksiJPwUlxvPz/jxjj2mpNyMXUirncjH7Y8JwYl9mBsCgI9n o1yb6mfusiNKPRAJ4CNgnvpFaNpUFkV/bz8jDXm0+c7XGXQ9okt8SsVv9sS+QyWzmHK0 iFzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=edDTrhUtEQP1Jk6IJ37Gd5v2fus9tEAAWYNcz4Uh5bc=; b=NY6JA08q48s/gC5lNWY2LqT/SLuRKWNHdcEOZ45N4ir/OICQEAGfg10Ml52ZxgPftZ H8dvnMl7p8lv4fOCJixUHQxE4VZJj+TrYgTWQC3IsbAfk7jnvZeblrXKTcLlsUhuNvMk PM8WCwTKjoMD14qe9854vTXAUtc1hl4e6J3gBzT9qPXbj7c1A1Tp3fJOhi449u0j3q3Z vsMqh+oR5ekYz3YU9X3nXuL+FbzyKprTzgv8ccXpWDChKD/YsHrIloWJKaLaPYiNudTk H8i5dRhcv9Apyw1IiYGdFRSjTky7GV95NphZ7/KmpBnl2I58Jqpve2hxeDgFvi5WV5QZ CsVg== X-Gm-Message-State: AOAM533vuBYKqlJoP5TY/+8lF/pVJQ+fgqObN23nZ7uLffLxoKynUxTB jFjjFcIQjXGyv9IY5u6mff1b2g== X-Google-Smtp-Source: ABdhPJyjCAwcy88WYFfJPmtYO+CdW+xFoQzmwvfln+4AZq87sS2NpDAnXByB7FDawk5winCNdrdfEQ== X-Received: by 2002:a17:902:8490:b0:156:9846:240 with SMTP id c16-20020a170902849000b0015698460240mr47090034plo.141.1649950984709; Thu, 14 Apr 2022 08:43:04 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id q15-20020a056a00150f00b004fb28ea8d9fsm299723pfu.171.2022.04.14.08.43.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Apr 2022 08:43:04 -0700 (PDT) Date: Thu, 14 Apr 2022 08:43:01 -0700 From: Stephen Hemminger To: Jeff Daly Cc: Thomas Monjalon , "Wang, Haiyue" , "dev@dpdk.org" , "qi.z.zhang@intel.com" , "john.mcnamara@intel.com" Subject: Re: [PATCH] net/ixgbe: Treat 1G Cu SFPs as 1G SX on the X550 devices Message-ID: <20220414084301.509fe14a@hermes.local> In-Reply-To: References: <20220307223442.28012-1-jeffd@silicom-usa.com> <1889452.fIoEIV5pvu@thomas> <2937496.687JKscXgg@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Thu, 14 Apr 2022 15:11:46 +0000 Jeff Daly wrote: > > -----Original Message----- > > From: Thomas Monjalon > > Sent: Thursday, April 14, 2022 8:19 AM > > To: Wang, Haiyue > > Cc: Jeff Daly ; dev@dpdk.org; Stephen Douthit > > ; qi.z.zhang@intel.com; > > john.mcnamara@intel.com > > Subject: Re: [PATCH] net/ixgbe: Treat 1G Cu SFPs as 1G SX on the X550 > > devices > > > > Caution: This is an external email. Please take care when clicking links or > > opening attachments. > > > > > > 14/04/2022 14:13, Wang, Haiyue: > > > From: Thomas Monjalon > > > > 14/04/2022 03:31, Wang, Haiyue: > > > > > From: jeffd@silicom-usa.com > > > > > > From: Stephen Douthit > > > > > > > > > > > > 1G Cu SFPs are not officially supported on the X552/X553 family > > > > > > of devices but treat them as 1G SX modules since they usually > > > > > > work. Print a warning though since support isn't validated, > > > > > > similar to what already happens for other unofficially supported > > > > > > SFPs enabled via the allow_unsupported_sfps parameter inherited > > from the mainline Linux driver. > > > > > > > > > > > > Signed-off-by: Stephen Douthit > > > > > > Signed-off-by: Jeff Daly > > > > > > --- > > > > > > drivers/net/ixgbe/base/ixgbe_x550.c | 14 +++++++++++++- > > > > > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c > > > > > > b/drivers/net/ixgbe/base/ixgbe_x550.c > > > > > > index 8810d1658e..8d1bc6c80d 100644 > > > > > > --- a/drivers/net/ixgbe/base/ixgbe_x550.c > > > > > > +++ b/drivers/net/ixgbe/base/ixgbe_x550.c > > > > > > @@ -1538,9 +1538,21 @@ STATIC s32 > > > > > > ixgbe_supported_sfp_modules_X550em(struct ixgbe_hw *hw, bool > > > > *linear) > > > > > > > > > > NACK. > > > > > > > > > > As for 1G Cu SFP treating it as 1G SX, some 1G-Base-T SFP modules > > > > > require the use of RX_ILOS and some Intel Ethernet products don't > > support that. > > > > > > > > So what is the solution? > > > > > > > > > And the DPDK keeps the same design with kernel. > > > > > > > > It should not be a justification for limiting DPDK features. > > > > > > Um, this is upstream version driver to keep the same behavior. > > > > > > There are also some kind of custom release ... > > > > I don't understand. > > Upstream DPDK (and Linux) must support a maximum of hardware and > > setup. > > Why rejecting adding such compatibility? > > > > so, I will ask a question directly in case people just aren't inclined to make a suggestion > (and perhaps this should be also directed to the Linux kernel driver mailing list), but > if there's a driver option: module_param(allow_unsupported_sfp, uint, 0) to allow > enabling non-official support of some SFPs, then I can't image that it wouldn't also be > acceptable to add: module_param(cu_sfp_as sx, uint, 0) to be able to select whether > to enable this specific handling as well? > > if a patch of this nature is acceptable to Linux driver maintainers, then it would also be > here as well according to your explanation of the NACK, correct? Makes sense for DPDK to have a similar option to enable (at your own risk) SFP's. But: - there is no equivalent of module_params in DPDK; you will have to think of something - should print message that when enabled the driver is no longer supported. use at your own risk.