From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by dpdk.org (Postfix) with ESMTP id 6EB991B499 for ; Fri, 12 Oct 2018 12:12:22 +0200 (CEST) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20181012101221euoutp022bf4eb1feb60882c94f916e533f4b4fd~c1MsVyGre1950419504euoutp02J for ; Fri, 12 Oct 2018 10:12:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20181012101221euoutp022bf4eb1feb60882c94f916e533f4b4fd~c1MsVyGre1950419504euoutp02J DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1539339141; bh=y0Ze/lo14C8nDVXuBZPAw+frtBxxcrGi1VUgKdaMUP8=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=nkCarGS3CsO6cnVQvXJuBG3b/ZedwOfwm6Wz1+VOQS9PJyVHNOa7bwJXl7LpWcbPb SReMoUb5t47womCv9qgxmJK24f7ZAq5bXwkvtusUBz0E0eN9UDJFvo7QcBiMcl0Q1p ZJDJyIRcSbWt3KV3oUakgZMGZUed/4mUD900fb9w= Received: from eusmges3new.samsung.com (unknown [203.254.199.245]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20181012101220eucas1p2aa8f8d3968c7e0dee10acd592ad8b9a2~c1Mr6oc_r1042810428eucas1p2K; Fri, 12 Oct 2018 10:12:20 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges3new.samsung.com (EUCPMTA) with SMTP id BC.FD.04806.48370CB5; Fri, 12 Oct 2018 11:12:20 +0100 (BST) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20181012101219eucas1p15ec4079f2144dca8faac241f7b8d7e86~c1MrB5N3j3123931239eucas1p16; Fri, 12 Oct 2018 10:12:19 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20181012101219eusmtrp1e3005d864db3cf10c515b59102003bfe~c1MqzX4b72486624866eusmtrp1e; Fri, 12 Oct 2018 10:12:19 +0000 (GMT) X-AuditID: cbfec7f5-367ff700000012c6-03-5bc0738407cf Received: from eusmtip1.samsung.com ( [203.254.199.221]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id CE.E5.04284.38370CB5; Fri, 12 Oct 2018 11:12:19 +0100 (BST) Received: from [106.109.129.180] (unknown [106.109.129.180]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20181012101219eusmtip15368240e133b1db5e1cd53588deb6457~c1MqNNBic2731327313eusmtip1X; Fri, 12 Oct 2018 10:12:19 +0000 (GMT) To: "Zhao1, Wei" , "Zhang, Qi Z" , Laurent Hardy Cc: "Lu, Wenzhuo" , "Ananyev, Konstantin" , "stable@dpdk.org" , "dev@dpdk.org" From: Ilya Maximets Date: Fri, 12 Oct 2018 13:14:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0gUYRTl25l1R2nlc1S8WLS4aZKUWkYMEmkgKEIR2EOzh5tOPldlZ10f QYmKmUhrSm2tFFqouYav1ErMxyqKT9LtoSZoaD9UNHJV0lRyHCX/nXvuufeeA5ciaIPYkYqO V7OqeEWc3MKKbOxaHTyWxbWFek5uODMLi+9EzOf7qxLm1/pLkjH160hGV6O1YDZz1iXMm+Uh gmno30C+VMCQdhwFrBWXigNeNc+IAh7WG9AF8qrV6Qg2LlrDqjzOhFlFmcZ+EokbXErdSIEk HenCcpElBfgkjPWYyVxkRdH4NYLS4TaRUCwh6KvXEUJhRvA9N1+0OzI7/YPgMY3LEWzOnRBE vxHUjeeQfMMWX4KFlcItEUXZ4WRoee7GawhchqCkox3xGgt8FHorO7cxiV2gdKpewmN7HAyd kyXbvBTbQM+zaZLfY4kvQvcXFU8T2AEylirEApZBZkPRtlHATRKoLdQSwqwGDKZ8QjDtB2Pj rTsBbGG2W7gF+AD0FeaRAr4HE1kzSFiUg0Bn3NwZ8IH6uUEJb4LAR6C6yUOgz8Jc9up2RsDW MDJvI/ixhoJG3Q4thZxsWlA7w9/28h03jjC6YJbkI7l+T0j9nmT6Pcn0/+8WI9KAHNgkThnJ cl7xbLI7p1BySfGR7uEJyjq09UF9m93L71HL+i0jwhSS75P+edQaSosVGi5VaURAEXI7aXFM WygtjVCkprGqhJuqpDiWM6L9FCl3kJa9qA2lcaRCzcaybCKr2u2KKEvHdDS60n1wOHWiQ7so dhFnet4gfNzmgw4lVLsGeyNfb7VTXmBlzbWYKu/Bx9lx5iLtdeMDVFkxGeTq1KG0+XjqvEad nvg0ZYAMuTwQfqd3zd/U8C1lPrBGFiaet9d+vesydztj5pOsnfHyO/c2v+vwhytL7mnlsvEn RVPNsXRIlX+HnOSiFMfdCBWn+AeXNuloPQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsVy+t/xu7rNxQeiDRY/0bB492k7k8WV9p/s Fu//LGKxuHxmOovF9A39bBb/Ov6wW6z5epHZYuuZv4wOHB4X++8wevxasJTVY/Gel0wefVtW MQawROnZFOWXlqQqZOQXl9gqRRtaGOkZWlroGZlY6hkam8daGZkq6dvZpKTmZJalFunbJehl XL71lLngb3HFphuT2BsYpyd0MXJySAiYSLx68pAZxBYSWMoo8edAKERcSuLHrwusELawxJ9r XWxdjFxANe8ZJe682MgIkhAWCJV4920yUDMHh4hAucS7l0ogNcwCyxglbkzoY4Vo2MkmMfXR f7BJbAI6EqdWH2EEaeAVsJNYNDEIJMwioCqx9PEWdhBbVCBCYvXyF2DlvAKCEidnPmEBKecU CJE4frUIJMwsoC7xZ94lZghbXKLpy0pWCFteonnrbOYJjEKzkHTPQtIyC0nLLCQtCxhZVjGK pJYW56bnFhvqFSfmFpfmpesl5+duYgTG3LZjPzfvYLy0MfgQowAHoxIP74+J+6OFWBPLiitz DzFKcDArifAuyDoQLcSbklhZlVqUH19UmpNafIjRFOi3icxSosn5wHSQVxJvaGpobmFpaG5s bmxmoSTOe96gMkpIID2xJDU7NbUgtQimj4mDU6qBsVC4rFLmr84l7x337lqzajYtV2M9fMt6 yTzPPn6hPhun05pypokmzUE61sFhdYnfrsaca+V7sSR+xgnZeTmvF/ScV/RanbSMM0VYg5PB Q8bPftrOA0vm5V93tFx41rSrWs7hd9qOgH8vFqx7eegbd3/r9D8SYhnbry8OyAnez7ZFjIe3 Q99GiaU4I9FQi7moOBEAyPeS8s8CAAA= Message-Id: <20181012101219eucas1p15ec4079f2144dca8faac241f7b8d7e86~c1MrB5N3j3123931239eucas1p16@eucas1p1.samsung.com> X-CMS-MailID: 20181012101219eucas1p15ec4079f2144dca8faac241f7b8d7e86 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20180831123824eucas1p1cd2981c716c4764703e24c3eeb4d33c7 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20180831123824eucas1p1cd2981c716c4764703e24c3eeb4d33c7 References: <20180831123824eucas1p1cd2981c716c4764703e24c3eeb4d33c7~P_GOOSRuf0867908679eucas1p1K@eucas1p1.samsung.com> <039ED4275CED7440929022BC67E706115327FA5E@SHSMSX103.ccr.corp.intel.com> <20180910150708eucas1p220c16857c4277b311ddc000b9337d9cb~TEk8KngQJ1365413654eucas1p2a@eucas1p2.samsung.com> <039ED4275CED7440929022BC67E7061153284304@SHSMSX103.ccr.corp.intel.com> <20180912080338eucas1p1bfdacb30aa969cd607ccf99f64d6bf80~TmFveK2Dy2157121571eucas1p1U@eucas1p1.samsung.com> <20181011102428eucas1p2fe26b12282d2b456ddc2cb96ad7552f0~cht-bhDPv2507925079eucas1p2L@eucas1p2.samsung.com> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: fix busy polling while fiber link update X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 10:12:22 -0000 On 12.10.2018 12:19, Zhao1, Wei wrote: > Hi， > >> -----Original Message----- >> From: Ilya Maximets [mailto:i.maximets@samsung.com] >> Sent: Thursday, October 11, 2018 6:27 PM >> To: Zhao1, Wei ; Zhang, Qi Z ; >> Laurent Hardy >> Cc: Lu, Wenzhuo ; Ananyev, Konstantin >> ; stable@dpdk.org; dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: fix busy polling while fiber link >> update >> >> On 11.10.2018 12:56, Zhao1, Wei wrote: >>> Hi, Ilya Maximets AND laurent.hardy >> >> Hi, thanks for sharing your thoughts. >> Comments inline. >> >>> >>> >>>> -----Original Message----- >>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ilya Maximets >>>> Sent: Wednesday, September 12, 2018 4:05 PM >>>> To: Zhang, Qi Z ; dev@dpdk.org >>>> Cc: Lu, Wenzhuo ; Ananyev, Konstantin >>>> ; Laurent Hardy >>>> ; Dai, Wei ; >>>> stable@dpdk.org >>>> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: fix busy polling while >>>> fiber link update >>>> >>>> On 12.09.2018 09:49, Zhang, Qi Z wrote: >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Ilya Maximets [mailto:i.maximets@samsung.com] >>>>>> Sent: Monday, September 10, 2018 11:09 PM >>>>>> To: Zhang, Qi Z ; dev@dpdk.org >>>>>> Cc: Lu, Wenzhuo ; Ananyev, Konstantin >>>>>> ; Laurent Hardy >>>>>> ; Dai, Wei ; >>>>>> stable@dpdk.org >>>>>> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: fix busy polling while >>>>>> fiber link update >>>>>> >>>>>> On 04.09.2018 09:08, Zhang, Qi Z wrote: >>>>>>> Hi Ilya: >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ilya >>>>>>>> Maximets >>>>>>>> Sent: Friday, August 31, 2018 8:40 PM >>>>>>>> To: dev@dpdk.org >>>>>>>> Cc: Lu, Wenzhuo ; Ananyev, Konstantin >>>>>>>> ; Laurent Hardy >>>>>>>> ; Dai, Wei ; Ilya >>>>>>>> Maximets ; stable@dpdk.org >>>>>>>> Subject: [dpdk-dev] [PATCH] net/ixgbe: fix busy polling while >>>>>>>> fiber link update >>>>>>>> >>>>>>>> If the multispeed fiber link is in DOWN state, ixgbe_setup_link >>>>>>>> could take around a second of busy polling. This is highly >>>>>>>> inconvenient for the case where single thread periodically checks >>>>>>>> the >>>> link statuses. >>>>>>>> For example, OVS main thread periodically updates the link >>>>>>>> statuses and hangs for a really long time busy waiting on >>>>>>>> ixgbe_setup_link() for a DOWN fiber ports. For case with 3 down >>>>>>>> ports it hangs for a 3 seconds and unable to do anything including >> packet processing. >>>>>>>> Fix that by shifting that workaround to a separate thread by >>>>>>>> alarm handler that will try to set up link if it is DOWN. >>>>>>> >>>>>>> Does that mean we will block the interrupt thread for 3 seconds? >>>>>> >>>>>> Three times for one second. Other work could be scheduled between. >>>>>> IMHO, it's much better than blocking usual caller for 3 seconds. >>>>>> >>>>>>> Also, can we guarantee there will not be any race condition if we >>>>>>> call >>>>>> ixgbe_setup_link at another thread, the base code API is not >>>>>> assumed to be thread-safe as I know. >>>>>> >>>>>> The only user of 'ixgbe_setup_link' is 'ixgbe_dev_start', but it >>>>>> could be called only if device stopped. 'ixgbe_dev_stop' cancels the >> alarm. >>>>>> Race with 'link_update' avoided by 'IXGBE_FLAG_NEED_LINK_CONFIG' >>>> flag. >>>>> >>>>> I guess, it' not only about when ixgb_setup_link race with itself, >>>>> but also >>>> when it race with other APIs. >>>>> Also the concern is, even in current version, we can prove there is >>>>> no issue, >>>> how can we guarantee we are safe for future base code update? It's >>>> not designed as thread-safe. >>>>> For my option, the change is risky. >>>> >>>> In current implementation interrupt handler already calls the >>>> 'ixgbe_dev_link_update' which subsequently calls 'ixgbe_setup_link' >>>> in our case if LSC interrupts enabled. So, my change makes the driver >>>> even safer by moving 'ixgbe_setup_link' to the same interrupt thread. >>>> Otherwise two threads (interrupts handler and the link status >>>> checking >>>> thread) could call 'ixgbe_setup_link' simultaneously. >>>> >>>>> >>>>> Btw, since ixgbe support LSC, it is not necessary for "single thread >>>> periodically checks the link statuses", right? >>>> >>>> In current implementation it will take at least 5 seconds (4 + 1) for >>>> the interrupt handler to detect DOWN link state for ixgbe multispeed >>>> fiber. This is too much for many real world cases. >>> >>> I have reviewed this patch, now I agree with you of the point that >>> when port is down, " main thread periodically updates the link statuses and >> hangs for a really long time busy waiting on ixgbe_setup_link() for a DOWN >> fiber ports ". >>> This is introduced by a patch in the following: >>> SHA-1: c12d22f65b132c56db7b4fdbfd5ddce27d1e9572 >>> * net/ixgbe: ensure link status is updated >>> >>> Because in this patch, ixgbe_setup_link() is called with input parameter >> autoneg_wait_to_complete=1, this will cause loop check and sleep delay. >>> At least 82599 seems has this delay.(BTW, whivh type of NIC are you >>> use? X550 or 82599) >> >> I have 82599. >> >>> Your solution is add a eal_alarm_set for ixgbe_setup_link in the thread of >> PMD driver, and do the set up work in that thread, is that right? >>> And main thread avoid hang by the flag of >> IXGBE_FLAG_NEED_LINK_CONFIG. >>> I think this is a good idea for this problem, but it may cause problem >>> for other legacy user of ixgbe pmd, because their legacy code, which use >> main thread to check link state and setup_link when port is down, and they >> are not aware of it is done by other thread if add your patch. >> >> What are these applications? I see no public API for setup_link function. >> It's internal to driver and should not be used externally. >> Am I missing something? > > rte_eth_link_get() , it will also call the function of ixgbe_setup_link(). > rte_eth_link_get() does not call ixgbe_setup_link(). It only calls dev_ops->link_update(). > >> >>> >>> And is that ok if we change code in ixgbe_dev_link_update_share() to >>> >>> ixgbe_dev_link_update_share() >>> { >>> >>> /* check if it needs to wait to complete, if lsc interrupt is enabled */ >>> if (wait_to_complete == 0 || dev->data->dev_conf.intr_conf.lsc != 0) >>> wait = 0; >>> >>> if ((intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) && >>> ixgbe_get_media_type(hw) == ixgbe_media_type_fiber) { >>> speed = hw->phy.autoneg_advertised; >>> if (!speed) >>> ixgbe_get_link_capabilities(hw, &speed, &autoneg); >>> ixgbe_setup_link(hw, speed, wait); >>> } >>> } >>> >>> Then, your application can call rte_eth_link_get_nowait () to make >>> wait_to_complete=0 when doing periodic link state check, Which will not >> cause loop check and sleep delay. Legacy code of other user call >> rte_eth_link_get() will not be affected also. >>> But, I am NOT confident ,whether this will introduce new problem when >> set up link without wait! >>> So, this is just a discussion topic. >> >> Unfortunately this will not help. Take a look to the function >> 'ixgbe_setup_mac_link_multispeed_fiber()', which is the main problematic >> function here. 'wait_to_complete' here used only as argument for >> ixgbe_setup_mac_link(), and the busy waiting loops are outside of it. >> Regardless of the 'wait_to_complete' value, this function will busy poll the >> link for 1040 ms trying to setup 10GB speed and 140ms more trying to setup >> 1GB speed. After that, it will call itself recursively and wait again... Looks like I >> miscalculated last time. Right now it'll be more than 2 seconds for each down >> port since following patch merged: >> 8fc1f32fa615 ("net/ixgbe: wait longer for link after fiber MAC setup"). > > Yes, you are right, link state check loop in function ixgbe_setup_mac_link_multispeed_fiber() are not blocked by bool autoneg_wait_to_complete, > It will cause about 1s wait when port is down. > And also, can we update code in function ixgbe_setup_mac_link_multispeed_fiber() to block link state check loop using autoneg_wait_to_complete? > I am not sure. Because there is a comment for this loop check: > /* > * Wait for the controller to acquire link. Per IEEE 802.3ap, > * Section 73.10.2, we may have to wait up to 500ms if KR is > * attempted. 82599 uses the same timing for 10g SFI. > */ > It seems we have to wait for at least 500ms for spec requirement before we check link after configuration. > If that is true, we can not do any change to these loop check. > But why not main thread take some action to stop periodic link sate check when it find it has been hang or link is down? To find that device is DOWN, thread will have to call this function at least once for each port and wait a few seconds. And how in that case we'll know that device is UP again? As I already wrote in discussion for this patch, LSC is not an option, because it takes at least 5 seconds to detect link state change, which is way too much for many real world apps. > > > >> >>> >>> Hi, laurent.hardy >>> You are the author for the patch (* net/ixgbe: ensure link status is >> updated), why do you implement code that way? >>> Is that must that set up link with wait? >>> >>> ixgbe_setup_link(hw, speed, true); >>> >>> >>> >>>> >>>>> >>>>>> >>>>>>> >>>>>>> Regards >>>>>>> Qi >>>>>>> >>>>>>>> >>>>>>>> Fixes: c12d22f65b13 ("net/ixgbe: ensure link status is updated") >>>>>>>> CC: stable@dpdk.org >>>>>>>> >>>>>>>> Signed-off-by: Ilya Maximets >>>>>>>> --- >>>>>>>> drivers/net/ixgbe/ixgbe_ethdev.c | 43 >>>>>>>> ++++++++++++++++++++++++-------- >>>>>>>> 1 file changed, 32 insertions(+), 11 deletions(-) >>>>>>>> >>>>>>>> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c >>>>>>>> b/drivers/net/ixgbe/ixgbe_ethdev.c >>>>>>>> index 26b192737..a33b9a6e8 100644 >>>>>>>> --- a/drivers/net/ixgbe/ixgbe_ethdev.c >>>>>>>> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c >>>>>>>> @@ -221,6 +221,8 @@ static int ixgbe_dev_interrupt_action(struct >>>>>>>> rte_eth_dev *dev, >>>>>>>> struct rte_intr_handle *handle); >> static >>>> void >>>>>>>> ixgbe_dev_interrupt_handler(void *param); static void >>>>>>>> ixgbe_dev_interrupt_delayed_handler(void *param); >>>>>>>> +static void ixgbe_dev_setup_link_alarm_handler(void *param); >>>>>>>> + >>>>>>>> static int ixgbe_add_rar(struct rte_eth_dev *dev, struct >>>>>>>> ether_addr *mac_addr, >>>>>>>> uint32_t index, uint32_t pool); static void >>>>>>>> ixgbe_remove_rar(struct rte_eth_dev *dev, uint32_t index); @@ >>>>>>>> -2791,6 +2793,8 @@ ixgbe_dev_stop(struct rte_eth_dev *dev) >>>>>>>> >>>>>>>> PMD_INIT_FUNC_TRACE(); >>>>>>>> >>>>>>>> + rte_eal_alarm_cancel(ixgbe_dev_setup_link_alarm_handler, >> dev); >>>>>>>> + >>>>>>>> /* disable interrupts */ >>>>>>>> ixgbe_disable_intr(hw); >>>>>>>> >>>>>>>> @@ -3969,6 +3973,25 @@ ixgbevf_check_link(struct ixgbe_hw *hw, >>>>>>>> ixgbe_link_speed *speed, >>>>>>>> return ret_val; >>>>>>>> } >>>>>>>> >>>>>>>> +static void >>>>>>>> +ixgbe_dev_setup_link_alarm_handler(void *param) { >>>>>>>> + struct rte_eth_dev *dev = (struct rte_eth_dev *)param; >>>>>>>> + struct ixgbe_hw *hw = >>>>>>>> IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private); >>>>>>>> + struct ixgbe_interrupt *intr = >>>>>>>> + IXGBE_DEV_PRIVATE_TO_INTR(dev->data- >>> dev_private); >>>>>>>> + u32 speed; >>>>>>>> + bool autoneg = false; >>>>>>>> + >>>>>>>> + speed = hw->phy.autoneg_advertised; >>>>>>>> + if (!speed) >>>>>>>> + ixgbe_get_link_capabilities(hw, &speed, &autoneg); >>>>>>>> + >>>>>>>> + ixgbe_setup_link(hw, speed, true); >>>>>>>> + >>>>>>>> + intr->flags &= ~IXGBE_FLAG_NEED_LINK_CONFIG; } >>>>>>>> + >>>>>>>> /* return 0 means link status changed, -1 means not changed */ >>>>>>>> int ixgbe_dev_link_update_share(struct rte_eth_dev *dev, @@ - >>>> 3981,9 >>>>>>>> +4004,7 @@ ixgbe_dev_link_update_share(struct rte_eth_dev >> *dev, >>>>>>>> IXGBE_DEV_PRIVATE_TO_INTR(dev->data- >>> dev_private); >>>>>>>> int link_up; >>>>>>>> int diag; >>>>>>>> - u32 speed = 0; >>>>>>>> int wait = 1; >>>>>>>> - bool autoneg = false; >>>>>>>> >>>>>>>> memset(&link, 0, sizeof(link)); >>>>>>>> link.link_status = ETH_LINK_DOWN; @@ -3993,13 +4014,8 >> @@ >>>>>>>> ixgbe_dev_link_update_share(struct >>>>>> rte_eth_dev >>>>>>>> *dev, >>>>>>>> >>>>>>>> hw->mac.get_link_status = true; >>>>>>>> >>>>>>>> - if ((intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) && >>>>>>>> - ixgbe_get_media_type(hw) == >> ixgbe_media_type_fiber) { >>>>>>>> - speed = hw->phy.autoneg_advertised; >>>>>>>> - if (!speed) >>>>>>>> - ixgbe_get_link_capabilities(hw, &speed, >> &autoneg); >>>>>>>> - ixgbe_setup_link(hw, speed, true); >>>>>>>> - } >>>>>>>> + if (intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) >>>>>>>> + return rte_eth_linkstatus_set(dev, &link); >>>>>>>> >>>>>>>> /* check if it needs to wait to complete, if lsc interrupt is >> enabled */ >>>>>>>> if (wait_to_complete == 0 || dev->data- >>> dev_conf.intr_conf.lsc >>>>>>>> != >>>>>>>> 0) @@ >>>>>>>> -4017,11 +4033,14 @@ ixgbe_dev_link_update_share(struct >>>> rte_eth_dev >>>>>> *dev, >>>>>>>> } >>>>>>>> >>>>>>>> if (link_up == 0) { >>>>>>>> - intr->flags |= IXGBE_FLAG_NEED_LINK_CONFIG; >>>>>>>> + if (ixgbe_get_media_type(hw) == >> ixgbe_media_type_fiber) >>>> { >>>>>>>> + intr->flags |= >> IXGBE_FLAG_NEED_LINK_CONFIG; >>>>>>>> + rte_eal_alarm_set(10, >>>>>>>> + >> ixgbe_dev_setup_link_alarm_handler, dev); >>>>>>>> + } >>>>>>>> return rte_eth_linkstatus_set(dev, &link); >>>>>>>> } >>>>>>>> >>>>>>>> - intr->flags &= ~IXGBE_FLAG_NEED_LINK_CONFIG; >>>>>>>> link.link_status = ETH_LINK_UP; >>>>>>>> link.link_duplex = ETH_LINK_FULL_DUPLEX; >>>>>>>> >>>>>>>> @@ -5128,6 +5147,8 @@ ixgbevf_dev_stop(struct rte_eth_dev >> *dev) >>>>>>>> >>>>>>>> PMD_INIT_FUNC_TRACE(); >>>>>>>> >>>>>>>> + rte_eal_alarm_cancel(ixgbe_dev_setup_link_alarm_handler, >> dev); >>>>>>>> + >>>>>>>> ixgbevf_intr_disable(dev); >>>>>>>> >>>>>>>> hw->adapter_stopped = 1; >>>>>>>> -- >>>>>>>> 2.17.1 >>>>>>>