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 9D02341BE9 for ; Mon, 6 Feb 2023 10:16:00 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9331040FAE; Mon, 6 Feb 2023 10:16:00 +0100 (CET) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by mails.dpdk.org (Postfix) with ESMTP id 551DC40A7A; Mon, 6 Feb 2023 10:15:58 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 94B8332008FD; Mon, 6 Feb 2023 04:15:55 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 06 Feb 2023 04:15:56 -0500 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=fm3; t=1675674955; x= 1675761355; bh=P1D99iYGkVW/QrvZY4lFMjCgkqEmRdWYJv1UdI30iTw=; b=c viy+MzeOsmu0TkHQOUsnpfaRdVAns5kF/HRwp5b9vfeq2H6qVCJoLjQwrbioQBxa 2pO8zdTDROPx8M/KkbT99cYHEtbqrKL491aIFvs503xYl9hY+PFo7inrghmF/HrU AzIDB+0/DeHQcirvJsY1qbNd2lNneFPo0q8VOKvzHsrPQAjb1f/JJSMbReKnb5EY JcJ5K5/UpUbEKB67t12xA9Yo8uCtQq3y5xHZMTZuqIjDhGPEiSiPQIq7ivFZoGXC 6c2GzSFoRjSo/v5ScstEtrO5VhU4rW15PlFZdm7gawEY4u/CEHoYBNDk+HIfxOl6 aLU0VVjnwxibRSNkN8Wqw== 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=fm3; t=1675674955; x= 1675761355; bh=P1D99iYGkVW/QrvZY4lFMjCgkqEmRdWYJv1UdI30iTw=; b=X iUxftXMLADaOj8fOdAJOjbPfCtK94wcahXIm42NbqzZTgDI8FDdb2AhPdfrnbMrQ /PJD9I5+PG/c68LfjcL79J4a1C67YrfT5UfztkEFmIXSkOSC0MAUmyP22TvH0z9D TrUZTeRc1++5E6otPlB/UDrylxx2LBBpWxkw5qTjC6uiDi4dgI+pRywtMJBat3Tx YgIPPfZiH7mV/XGp+s8OaRea5XMqhWAPdy1P8bkx20jLvPZ19CXGGkcDOmWZWhbg wBoRj6Ob9DNbO7aCP9mNNYEuuG5qez4uUjMSsAXH3KImatIzezBikCSfzeI0Q3dz QER3lo6zRvSHB06S3AL1g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudegiecutefuodetggdotefrodftvfcurf hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgrshcu ofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuggftrf grthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieekgfek udehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 6 Feb 2023 04:15:53 -0500 (EST) From: Thomas Monjalon To: "Ye, MingjinX" Cc: "dev@dpdk.org" , "stable@dpdk.org" , "Zhou, YidingX" , "Yang, Qiming" , "Zhang, Qi Z" , "david.marchand@redhat.com" , "ferruh.yigit@amd.com" Subject: Re: [PATCH] net/ice: fix get link status timeout Date: Mon, 06 Feb 2023 10:15:52 +0100 Message-ID: <3175550.aV6nBDHxoP@thomas> In-Reply-To: References: <20230206062239.1042172-1-mingjinx.ye@intel.com> <13196161.dW097sEU6C@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org 06/02/2023 09:14, Ye, MingjinX: > From: Thomas Monjalon > > 06/02/2023 07:22, Mingjin Ye: > > > When hw is just started, it will immediately obtain the link status, > > > and the longest attempt is 1 second. Some NICs are slow to initialize, > > > which make it fails to obtain the link status. > > > > > > The patch fixes this issue by modifying the longest attempt to 5 seconds. > > > > What is the consequence? > > DPDK could not get link status. At this point, the link status obtained through > the pmd API is wrong. > > > In which case, DPDK application would be blocked during 5 seconds? > > When the dpdk application startup port is used, it will be blocked for up > to 5 seconds to ensure that the connection status can be obtained. I mean what is the consequence of the increase? For example, if the port is not connected (no wire), are we going to wait 5 seconds? I guess it's OK because it won't wait at all if using rte_eth_link_get_nowait. It may be interesting to note in the commit message.