<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 > >> > >
