From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by dpdk.org (Postfix) with ESMTP id F1A18239 for ; Mon, 15 Oct 2018 10:37:48 +0200 (CEST) Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20181015083747euoutp01e65ba8ffb0a2e1416f7718e79d08f490~du1-Hg7fS0711007110euoutp01F for ; Mon, 15 Oct 2018 08:37:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20181015083747euoutp01e65ba8ffb0a2e1416f7718e79d08f490~du1-Hg7fS0711007110euoutp01F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1539592667; bh=dReZNHEvhp30iNZsNkAJsF9UvXlyYgO+pAI+mmTqiiw=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=KzZEMiScnbXPl3MdhNtmQ7OlalPzzJ1x5JBJvSnt5bDed0egEi5/VsUEVjYacw+90 3IECctvO6ouJjpApYwraq/6FGGqNWamkY4lxQg7UhFwIBSccajXS66YCWyar2O9Eu9 uc565gqz34heUQIjhpyWykCbdx9sNx69Y/GH9kEk= Received: from eusmges3new.samsung.com (unknown [203.254.199.245]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20181015083746eucas1p19845ee314a6bddc247cfc14885b5359e~du1_eUHhl1784117841eucas1p1c; Mon, 15 Oct 2018 08:37:46 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges3new.samsung.com (EUCPMTA) with SMTP id 17.BA.04806.AD154CB5; Mon, 15 Oct 2018 09:37:46 +0100 (BST) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20181015083746eucas1p10736210af8e85e7e155e7289be855452~du19oFpAT1784617846eucas1p1V; Mon, 15 Oct 2018 08:37:46 +0000 (GMT) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20181015083745eusmtrp1b128fd10ab5e82254b059b7b2aac2880~du19ZP93C0292502925eusmtrp1k; Mon, 15 Oct 2018 08:37:45 +0000 (GMT) X-AuditID: cbfec7f5-34dff700000012c6-5b-5bc451dabaab Received: from eusmtip1.samsung.com ( [203.254.199.221]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id A2.B9.04128.9D154CB5; Mon, 15 Oct 2018 09:37:45 +0100 (BST) Received: from [106.109.129.180] (unknown [106.109.129.180]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20181015083745eusmtip186fe84c30f7f195a47be1167d2ab7859~du1824ZiN1569015690eusmtip1L; Mon, 15 Oct 2018 08:37:45 +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: Mon, 15 Oct 2018 11:40:18 +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: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsWy7djP87q3Ao9EG0x8pGHx7tN2Josr7T/Z Ld7/WcRicfnMdBaL6Rv62Sz+dfxht1jz9SKzxdYzfxkdODwu9t9h9Pi1YCmrx+I9L5k8+ras YgxgieKySUnNySxLLdK3S+DKeHJ8I1vB90bGiucH5rE2MN7M6WLk4JAQMJFYuiKri5GLQ0hg BaPE7Ifr2CGcL4wS/zqesUE4n4EyN5uZuhg5wTpu/9zLApFYzijx5M4jqJaPjBITH95kA6kS FgiVePdtMjPIDhGBcol9c7VAapgFljFKLDx8kBGkhk1AR+LU6iNgNouAqsSqW0fBNogKREgc ebAQLM4rIChxcuYTFhCbUyBE4sOuR2DzmQXEJZq+rGSFsOUlmrfOZgZZICGwj13iQ/9Ldojm MokHG06xQJztInHtfwsjhC0s8er4FnYIW0bi9OQeqJp6ifstLxkhBnUwSkw/9A/qZ3uJLa/P sYN8wyygKbF+lz5E2FHiddtPZkhA8knceCsIcQ+fxKRt06HCvBIdbUIQ1SoSvw8uZ4awpSRu vvvMPoFRaRaSL2ch+WwWks9mIexdwMiyilE8tbQ4Nz212DgvtVyvODG3uDQvXS85P3cTIzAN nf53/OsOxn1/kg4xCnAwKvHwCvAciRZiTSwrrsw9xCjBwawkwisRcihaiDclsbIqtSg/vqg0 J7X4EKM0B4uSOO+yeRujhQTSE0tSs1NTC1KLYLJMHJxSDYyzI1bopDfEZ/Oe7O5mnXrdZeWu JyJ7i1aopa9tnaRme46v88OyCSv2OutWitfdTfW2crOQq9nQ5aWad5WvzO58YyX/5di5y+Tj HTtW/JavKb56JLNQYdvXBb4BensdLI4bLD+pJ7S44fG/dj7bm/x8n12Tju/bzizckqHemB7f Exfv5abkocRSnJFoqMVcVJwIABOJWxI/AwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsVy+t/xu7o3A49EG3zdaGDx7tN2Josr7T/Z Ld7/WcRicfnMdBaL6Rv62Sz+dfxht1jz9SKzxdYzfxkdODwu9t9h9Pi1YCmrx+I9L5k8+ras YgxgidKzKcovLUlVyMgvLrFVija0MNIztLTQMzKx1DM0No+1MjJV0rezSUnNySxLLdK3S9DL eHJ8I1vB90bGiucH5rE2MN7M6WLk5JAQMJG4/XMvSxcjF4eQwFJGiQe9F5ghElISP35dYIWw hSX+XOtigyh6zygxd/sDNpCEsECoxLtvk4EaODhEBMol3r1UAqlhFljGKHFjQh8rRMMHdomL G7exgDSwCehInFp9hBGkgVfATuLuaU2QMIuAqsSqW0eZQGxRgQiJ1ctfgC3mFRCUODnzCVgr p0CIxIddj8D2MguoS/yZd4kZwhaXaPqykhXClpdo3jqbeQKj0Cwk7bOQtMxC0jILScsCRpZV jCKppcW56bnFRnrFibnFpXnpesn5uZsYgZG37djPLTsYu94FH2IU4GBU4uEV4DkSLcSaWFZc mXuIUYKDWUmEVyLkULQQb0piZVVqUX58UWlOavEhRlOg5yYyS4km5wOTQl5JvKGpobmFpaG5 sbmxmYWSOO95g8ooIYH0xJLU7NTUgtQimD4mDk6pBsaKV0tNG5/xfz7o+1nv+3xj55JTX7Oi ZgjOSgp6LiT+IYW//HnO1iNbJsxO/LjU/9jJOQtPHNLceSD5I/cEhmds51aayC//OyEgYO7p 67s+r9nasPn9ab7F7fxXts3ZnP9mSWjvyYXqhRMnPTq8Klc349cM2zRtIebnzIy/Nh5c5LMy 0f3l7m8y3EosxRmJhlrMRcWJAFjpvGLSAgAA Message-Id: <20181015083746eucas1p10736210af8e85e7e155e7289be855452~du19oFpAT1784617846eucas1p1V@eucas1p1.samsung.com> X-CMS-MailID: 20181015083746eucas1p10736210af8e85e7e155e7289be855452 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> <20181012101219eucas1p15ec4079f2144dca8faac241f7b8d7e86~c1MrB5N3j3123931239eucas1p16@eucas1p1.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: Mon, 15 Oct 2018 08:37:49 -0000 On 15.10.2018 06:03, Zhao1, Wei wrote: > Hi， Ilya Maximets > >> -----Original Message----- >> From: Ilya Maximets [mailto:i.maximets@samsung.com] >> Sent: Friday, October 12, 2018 6:15 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 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(). > > No, dev_ops->link_update call function ixgbe_dev_link_update() > -> ixgbe_dev_link_update_share() -> ixgbe_setup_link() But with my patch, calling of ixgbe_setup_link() happens in a separate (interrupt) thread. There is no direct call from ixgbe_dev_link_update_share(). All the calls from the interrupt thread are sequenced by implementation. > > >> >>> >>>> >>>>> >>>>> 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 >>>>>>>>>