17/02/2020 14:01, Ferruh Yigit:
> On 2/15/2020 3:41 PM, Ye Xiaolong wrote:
> > On 01/15, taox....@intel.com wrote:
> >> From: Zhu Tao <taox....@intel.com>
> >>
> >> IXGBE link status task use rte alarm thread in old implementation.
> >
> > s/use/uses
> >
> >> 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
> >
> >> 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")
> >
> >> Cc: sta...@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?
