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 7A7102BBD for ; Wed, 3 Oct 2018 09:41:08 +0200 (CEST) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20181003074107euoutp014db61b410ba6fd7066b5f302f7db7e8b~aCVE0yltt2347823478euoutp010 for ; Wed, 3 Oct 2018 07:41:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20181003074107euoutp014db61b410ba6fd7066b5f302f7db7e8b~aCVE0yltt2347823478euoutp010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1538552467; bh=Bx2R5uE/EjwbGcw1SwhZdiu3Z3XSqo+wS+ik7ChfzxA=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=ag/CXRl96ffJe/8gl/mOPLbnuvasYuEigEodazYRfKZgdhqibukiiezS0jiSov0LJ 5y+yIsPE2QwbDVJU9yfUEAhCZNB+12jhBWu7b/VW6CeMOS7RHfPtaJoVh0f5jsn6EP iDknvp/r54WBABXmhHXA09YYlPBTC0d4d9Y3P8dk= Received: from eusmges1new.samsung.com (unknown [203.254.199.242]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20181003074106eucas1p29c8edc8dd67686daf06ac1e9171f6601~aCVEUj4YJ3122631226eucas1p2T; Wed, 3 Oct 2018 07:41:06 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges1new.samsung.com (EUCPMTA) with SMTP id 75.08.04441.29274BB5; Wed, 3 Oct 2018 08:41:06 +0100 (BST) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20181003074105eucas1p19452a3d3d788e58be6eaab36295775a6~aCVDfgCVZ0655806558eucas1p1H; Wed, 3 Oct 2018 07:41:05 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20181003074105eusmtrp15f8ee39ad0504f15ef97bdc746e1d39d~aCVDORk313070230702eusmtrp1Y; Wed, 3 Oct 2018 07:41:05 +0000 (GMT) X-AuditID: cbfec7f2-5e3ff70000001159-2d-5bb472921420 Received: from eusmtip2.samsung.com ( [203.254.199.222]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id E5.4B.04284.19274BB5; Wed, 3 Oct 2018 08:41:05 +0100 (BST) Received: from [106.109.129.180] (unknown [106.109.129.180]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20181003074104eusmtip22e00f9cc1dcd497c6e7d3244d90e3562~aCVCdlIqx0656806568eusmtip2K; Wed, 3 Oct 2018 07:41:04 +0000 (GMT) To: "Zhang, Qi Z" , "dev@dpdk.org" Cc: "Lu, Wenzhuo" , "Ananyev, Konstantin" , Laurent Hardy , "Dai, Wei" , "stable@dpdk.org" , Thomas Monjalon , Ferruh Yigit From: Ilya Maximets Date: Wed, 3 Oct 2018 10:43: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: <039ED4275CED7440929022BC67E706115329F90B@SHSMSX103.ccr.corp.intel.com> Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGeXfvdu+Wk+s0PKxEm/5T2VSwuEFYYdQKooIKS8RuelHJqeyq +VGk4ceQ1FTYcITNLL9K/FpOU8vM1JoYmpWCpYUWapr5haZJzqvkf79znvOc9zzwkpisUSgn wyKiWU0EE64QSfC69qV3+3I1Jn/P5z3b6KkZs4AebLYQdF/6EkH/WnmA0++79Ditr8oW0ava FYKeGe7E6ZbxFJx+2vUXHZGoerIHkeqP8ZFQVdQ0JlC1D+gIVZapHJ0VXpYcCmbDw2JZjYfP FUloSWaOMOq+e1zFz04sCQ25ZSAxCZQ3vB5twzKQhJRRpQhetXcSfDGHIHl0VsQXswj6HzYK Ny1Fn1M3LCUISpd1OF/8RjBdU42sU/bUBZhayMOs7ECdgB+pSULrEEYZBWAc1Qqsgohyh7eP 29YNOOUGLeZFwsrbKT9oGy5c70spO3iTP4JbWUydh6qWpnXGKEe4PVcm5NkZzJP31k8CqpuA +mQdwZtjIbvRGoJcE47BR7MrH8EexjtMBM87wZJ3B+f5FgyljCF+jxaBvnVVwAuHwTTRTVj3 YNRuqHzmwbePwkTaEsavt4X+STv+HFvIrdNvtKWgTZPx026w/LIE41kOA1OzxF2kMGwJadgS zLAlmOH/u0aElyNHNoZTh7CcVwR7Xckxai4mIkQZFKmuQWtfyrLaMVOP5nuvtiKKRAobaX1h rb9MyMRy8epWBCSmcJBmMWstaTATn8BqIgM1MeEs14p2kLjCUVpcUO0vo0KYaPYay0axmk1V QIrlSSgxqKBZvJ9YPJCWmWg5VWy00dloU1O+3gxxNxiXcuZzysxRRaYZ3/Rei7K/XO75vSHB pUS/4PMi3ym8YdTb+yRltFwKTPGWP/GNd1GOfJg+tzezqLZ9TBlQIQ7Y1f3NzzWOO55QLL8h 0jk5h2KrBz+pmYtn+ornvthEVSZXnm5S4Fwo47UH03DMP25paxBOAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsVy+t/xe7oTi7ZEG6x8wm/x7tN2Jos7e0+z W1xp/8lu8f7PIhaLy2ems1hM39DPZvGv4w+7xacHJ1gsDrxqYbHYeuYvowOXx8X+O4wevxYs ZfVYvOclk8exm9PYPfq2rGIMYI3SsynKLy1JVcjILy6xVYo2tDDSM7S00DMysdQzNDaPtTIy VdK3s0lJzcksSy3St0vQy1jeO5G1YL5Oxdo3J5gbGO+rdDFyckgImEgsvtvK3MXIxSEksJRR 4uuhD4wQCSmJH78usELYwhJ/rnWxgdhCAu8ZJY70uYLYwgKhEu++TWYGsUUE3CWetzawggxi FljEJPF24UpWiKlnWCVO3vvODlLFJqAjcWr1EbANvAJ2EivOrmQBsVkEVCQObP8BViMqECGx evkLVogaQYmTM5+A1XAKhEhsOLAHzGYWUJf4M+8SM4QtLtH0ZSUrhC0vsf3tHOYJjEKzkLTP QtIyC0nLLCQtCxhZVjGKpJYW56bnFhvqFSfmFpfmpesl5+duYgTG5bZjPzfvYLy0MfgQowAH oxIP746Fm6OFWBPLiitzDzFKcDArifD2JQKFeFMSK6tSi/Lji0pzUosPMZoCPTeRWUo0OR+Y MvJK4g1NDc0tLA3Njc2NzSyUxHnPG1RGCQmkJ5akZqemFqQWwfQxcXBKNTCWf5253d3R1fn8 ymUCN2pDpWw9o6a/Tr60XyNh3WlvhXMO29+3Zt8RPiuoe+dISfz3Uz/6/35kV5r3vUVcLP7p ZrcF0ufCPKbPLPe6kDZ5U6/xef2Jcs911bhW1uknRM7Y1mL99FG47veGlDu5/6f32Ei8EZx+ 7EDYFPPXUYVvnjSHuHTvMzNUYinOSDTUYi4qTgQAhX2Qh+ECAAA= Message-Id: <20181003074105eucas1p19452a3d3d788e58be6eaab36295775a6~aCVDfgCVZ0655806558eucas1p1H@eucas1p1.samsung.com> X-CMS-MailID: 20181003074105eucas1p19452a3d3d788e58be6eaab36295775a6 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> <039ED4275CED7440929022BC67E7061153284408@SHSMSX103.ccr.corp.intel.com> <039ED4275CED7440929022BC67E706115329F90B@SHSMSX103.ccr.corp.intel.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: Wed, 03 Oct 2018 07:41:08 -0000 On 21.09.2018 17:25, Zhang, Qi Z wrote: > > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zhang, Qi Z >> Sent: Wednesday, September 12, 2018 4:29 PM >> To: Ilya Maximets ; 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 >> >> >> >>> -----Original Message----- >>> From: Ilya Maximets [mailto:i.maximets@samsung.com] >>> 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. >> >> Ok, you are right, seems the concern I have is already exist , your patch does >> not introduce new issue. >> So I have no objection if this will fix some issue. >> But let's check if any ixgbe experts will comment. >> >> Regards >> Qi >> >>> >>>> >>>> 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. >>> >>>> >>>>> >>>>>> >>>>>> Regards >>>>>> Qi >>>>>> >>>>>>> >>>>>>> Fixes: c12d22f65b13 ("net/ixgbe: ensure link status is updated") >>>>>>> CC: stable@dpdk.org >>>>>>> >>>>>>> Signed-off-by: Ilya Maximets > > Reviewed-by: Qi Zhang Hi. Is there any chance for this to be merged in a near future? Situation becomes even worse. Recently accepted commit b2815c41bd0b ("net/ixgbe: wait longer for link after fiber MAC setup") increases the time of the thread hang busy waiting up to 1.5 seconds per port on each link state check. Best regards, Ilya Maximets.