RE: [PATCH 1/5] ethdev: fix race-condition of proactive error handling mode

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

<snip>

> >>>>>
> >>>
> >>> Is there any reason not to design this in the same way as
> >> 'rte_eth_dev_reset'? Why does the PMD have to recover by itself?
> >>
> >> I suppose it is a question for the authors of original patch...
> > Appreciate if the authors could comment on this.
> 
> The main cause is that the hardware implementation limit, I will try to explain
> from hns3 PMD's view.
> For a global reset, all the function need responsed within a centain period of
> time. otherwise, the reset will fail. and also the reset requirement a few steps (all
> may take a long time).
> 
> When with multiple functions in one DPDK, and trigger a global reset, the
> rte_eth_dev_reset will not cover this scene:
> 1. each port's will report RTE_ETH_EVENT_INTR_RESET in interrupt thread.
> 2. then invoke application callback, but due to the same thread, and each
>     port's recover will take a long time, so later port will reset failed.
If the design were to introduce RTE_ETH_EVENT_INTR_RECOVER and rte_eth_dev_recover, what problems do you see?

> 
> >
> >>
> >>> We could have a similar API 'rte_eth_dev_recover' to do the recovery
> >> functionality.
> >>
> >> I suppose such approach is also possible.
> >> Personally I am fine with both ways: either existing one or what you
> >> propose, as long as we'll fix existing race-condition.
> >> What is good with what you suggest - that way we probably don't need
> >> to worry how to allow user to enable/disable auto-recovery inside PMD.
> >>
> >> Konstantin
> >>
> >