21/02/2020 09:19, Zhu, TaoX:

Hi Thomas
 
Thank you for your correction spelling error of 'cancel'.

Indeed it is not the best solution by creating a thread. I refer to the same solution with Linux kernel driver. Linux kernel driver manages link status by using a thread. Maybe we can figure out another better solution to fix this problem but it may take much more time. At this time, 20.02 formal release is coming and this problem affect some basic library. 
Tks for your understanding.

I understand, that's why I already accepted this patch in mainline (while fixing typo).

Please it would be really appreciated to work on a better solution.

quoted

-----Original Message-----
From: Thomas Monjalon [mailto:thomas@monjalon.net]
Sent: Thursday, February 20, 2020 11:37 PM
To: Ye, Xiaolong <redacted>; Zhu, TaoX <redacted>;
Yigit, Ferruh [off-list ref]
Cc: dev@dpdk.org; Ananyev, Konstantin <redacted>;
Lu, Wenzhuo [off-list ref]; stable@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix blocking system events

17/02/2020 14:01, Ferruh Yigit:

quoted

On 2/15/2020 3:41 PM, Ye Xiaolong wrote:

quoted

On 01/15, taox.zhu@intel.com wrote:

quoted

From: Zhu Tao <redacted>

IXGBE link status task use rte alarm thread in old implementation.

s/use/uses

quoted

Sometime ixgbe link status task takes up to 9 seconds. This will
severely affect the rte-alarm-thread-dependent a task in the
system, like interrupt or hotplug event. So replace with a

s/a/an

quoted

independent thread which has the same thread affinity settings as
rte interrupt.

Fixes: 0408f47b ("net/ixgbe: fix busy polling while fiber link
update")

Should be:

Fixes: 0408f47ba4d6 ("net/ixgbe: fix busy polling while fiber link
update")

quoted

Cc: stable@dpdk.org

Applied to dpdk-next-net-intel with Konstantin's ack, Thanks.

Shared build is failing because of missing pthread library, fixing
while merging to next-net:

One more thing looks strange in this patch:
	ixgbe_dev_cannel_link_thread
Should it be
	ixgbe_dev_cancel_link_thread
?

Note: I looked at it because I am not sure multiplying the interrupt threads is
a good idea.
Basically the link status management is too long in this driver.
Instead of fixing the root cause, you move the annoying workload
somewhere else. But it is still there...

Please could you work on a long term fix?