From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 30CF7A0A03;
	Tue, 19 Jan 2021 03:58:53 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id AD6F2140D95;
	Tue, 19 Jan 2021 03:58:52 +0100 (CET)
Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35])
 by mails.dpdk.org (Postfix) with ESMTP id 3E7DE140D94;
 Tue, 19 Jan 2021 03:58:49 +0100 (CET)
Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58])
 by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4DKYHB1rmcz7WX4;
 Tue, 19 Jan 2021 10:57:42 +0800 (CST)
Received: from [10.67.103.128] (10.67.103.128) by
 DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id
 14.3.498.0; Tue, 19 Jan 2021 10:58:42 +0800
To: Stephen Hemminger <stephen@networkplumber.org>
CC: Bruce Richardson <bruce.richardson@intel.com>, <dev@dpdk.org>,
 <stable@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>, Ferruh Yigit
 <ferruh.yigit@intel.com>, Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
 Ciara Power <ciara.power@intel.com>, Keith Wiles <keith.wiles@intel.com>,
 Beilei Xing <beilei.xing@intel.com>, Jeff Guo <jia.guo@intel.com>, "Haiyue
 Wang" <haiyue.wang@intel.com>, Ajit Khaparde <ajit.khaparde@broadcom.com>,
 <somnath.kotur@broadcom.com>, <qiming.yang@intel.com>, <qi.z.zhang@intel.com>
References: <20210114121733.46801-1-bruce.richardson@intel.com>
 <4b5e9630-b331-f498-2488-d9418719ff8c@huawei.com>
 <20210118182614.63f1d5d2@hermes.local>
From: "Min Hu (Connor)" <humin29@huawei.com>
Message-ID: <52dbf960-6d9e-5070-cde1-27c5a1e32e97@huawei.com>
Date: Tue, 19 Jan 2021 10:58:42 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.3.1
MIME-Version: 1.0
In-Reply-To: <20210118182614.63f1d5d2@hermes.local>
Content-Type: text/plain; charset="gbk"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.67.103.128]
X-CFilter-Loop: Reflected
Subject: Re: [dpdk-dev] [PATCH] ethdev: avoid blocking telemetry callback
 for link status
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Thank Stephen,
but in which the scenarios, it should wait link to up, in which
scenarios, it should not ?
By the way, how to define the "wait" time value ?


在 2021/1/19 10:26, Stephen Hemminger 写道:
> On Tue, 19 Jan 2021 09:06:48 +0800
> "Min Hu (Connor)" <humin29@huawei.com> wrote:
> 
>> Hi, Bruce and all,
>> 	Do you know the difference between "rte_eth_link_get" and
>> "rte_eth_link_get_nowait"? I know they call funciton "link_update"
>> with differenct parameter "wait_to_complete"(set 1 means wait, set 0
>>    means not wait). But how to define the "wait" time, and why it shoud wait?
>> 	On the further, What are the application scenarios of the two
>> APIs?
>>
> 
> The default behavior of rte_eth_link_get (in some drivers) is to wait
> for link to come up.  Many drivers don't do this. It seems mostly the
> Intel ones that do.
> .
>