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 0A65DA0032; Thu, 12 May 2022 03:39:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9F529410EF; Thu, 12 May 2022 03:39:24 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 99E9440E64; Thu, 12 May 2022 03:39:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652319562; x=1683855562; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Bi/snHyxOYr1M2sMBnARLdtV8TKAbI7Y6qtY4Z6pHKM=; b=iDUrwaQINUFMNoizefhiCnTBh1DyFawJfoTtRAPBqJRJBM0ZUxH798QB L0O9Ab16eczNO0yCHM+zFfMYlzeRHQ8G7NZ5rj1CU2m1OVGJAwTMC/gUF qDJcvkNLP8FntRRijxmkhu9phfWqu7UPXmGdMhAWiOxBy+O8fz6q/RtZj xqRAGvasIF8u0RpEMud8PPRPqZt/IilR6sFMN9A1uLCULWbXca7cb44dt Ptk4BnlbzcnCpSzTUUvb5XA/kvQNs0m9GIbU74CbDLQzzVpqZMCzlI4eM ZfVSA/TxOY4x0sdqC4xYvk8sORsunoiDlSyyAjG91xGdt3YxlvjGVNP0n w==; X-IronPort-AV: E=McAfee;i="6400,9594,10344"; a="332897941" X-IronPort-AV: E=Sophos;i="5.91,218,1647327600"; d="scan'208";a="332897941" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 May 2022 18:39:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,218,1647327600"; d="scan'208";a="520748710" Received: from orsmsx606.amr.corp.intel.com ([10.22.229.19]) by orsmga003.jf.intel.com with ESMTP; 11 May 2022 18:39:20 -0700 Received: from fmsmsx601.amr.corp.intel.com (10.18.126.81) by ORSMSX606.amr.corp.intel.com (10.22.229.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Wed, 11 May 2022 18:39:20 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Wed, 11 May 2022 18:39:18 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Wed, 11 May 2022 18:26:34 -0700 Received: from fmsmsx612.amr.corp.intel.com ([10.18.126.92]) by fmsmsx612.amr.corp.intel.com ([10.18.126.92]) with mapi id 15.01.2308.027; Wed, 11 May 2022 18:26:34 -0700 From: "Zhang, Qi Z" To: Jeff Daly , "dev@dpdk.org" CC: "stable@dpdk.org" , Stephen Douthit Subject: RE: [PATCH v6 2/2] net/ixgbe: Fix SFP detection and linking on hotplug Thread-Topic: [PATCH v6 2/2] net/ixgbe: Fix SFP detection and linking on hotplug Thread-Index: AQHYTpWB4bOdPuOxG0+tKasVp21GiK0ansFQ Date: Thu, 12 May 2022 01:26:34 +0000 Message-ID: <6ed20a09404145869918a77a58670b67@intel.com> References: <20220228152937.21247-1-jeffd@silicom-usa.com> <20220412174220.31195-1-jeffd@silicom-usa.com> <20220412174220.31195-3-jeffd@silicom-usa.com> In-Reply-To: <20220412174220.31195-3-jeffd@silicom-usa.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.6.401.20 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 > -----Original Message----- > From: Jeff Daly > Sent: Wednesday, April 13, 2022 1:42 AM > To: dev@dpdk.org > Cc: stable@dpdk.org; Stephen Douthit ; Wang, > Haiyue > Subject: [PATCH v6 2/2] net/ixgbe: Fix SFP detection and linking on hotpl= ug >=20 > Currently the ixgbe driver does not ID any SFP except for the first one p= lugged > in. This can lead to no-link, or incorrect speed conditions. Does kernel driver has the same issue for this? >=20 > For example: >=20 > * If link is initially established with a 1G SFP, and later a 1G/10G mult= ispeed > part is later installed, then the MAC link setup functions are never call= ed to > change from 1000BASE-X to 10GBASE-R mode, and the link stays running at t= he > slower rate. >=20 > * If link is initially established with a 1G SFP, and later a 10G only mo= dule is > later installed, no link is established, since we are still trasnsmitting= in > 1000BASE-X mode to a 10GBASE-R only partner. >=20 > Refactor the SFP ID/setup, and link setup code, to more closely match the= flow > of the mainline kernel driver which does not have these issues. In that = driver a > service task runs periodically to handle these operations based on bit fl= ags that > have been set (usually via interrupt or userspace request), and then get = cleared > once the requested subtask has been completed. If kernel driver don't have this issue, Is this the same way that kernel dr= iver handle this issue? Btw, could you break down the patch for easy review? Thanks Qi