On Mon, Dec 23, 2019 at 2:44 PM Gavin Hu <gavin...@arm.com> wrote: > > Hi Jerin,
Hi Gavin, > > I think we are on the same page with regard to the problem, and the > situations, thanks for illuminating the historical background of the two > barriers. > About the solution, I added inline comments. > > It will be optimization only when if we are changing in the fast path. > > In the slow path, it does not matter. > > I think, the First step should be to use rte_cio_* wherever it is > > coherent memory used in _fast path_. I think, Almost every driver > > fixed that. > > > > I am not against this patch(changing the slow path to use rte_cio* > > from rte_io* and virtio changes associated with that). > > If you are taking that patch, pay attention to all the drivers in the > > tree which is using rte_io* for mixed access in slowpath. > I see 30+ drivers has calling rte_io* directly or indirectly through > rte_write/read*. > It is hard for me to figure out all the mixed accesses in these drivers, and > as you said, it makes no sense to change the _slow path_. > > How about we keep the old rte_io as is, and introduce 'fast path' version of > rte_io for new code use? > Then in future, we may merge the two? > Another reason about this proposal is maybe there is rte_io calling in the > fast path, but they are not mixed accesses and rte_cio is not suitable. Could you share more details about the case where fastpath + rte_io needed + rte_cio is not suitable? > > Any thoughts? > > > > > > But as the case in i40e, we must pay attention to where rte_cio was > > missing but rescued by old rte_io(but not by new rte_io). > > > > > >
