On 10/11/19 12:52 PM, Ido Schimmel wrote: > On Fri, Oct 11, 2019 at 11:47:12AM -0700, Wei Wang wrote: >> On Fri, Oct 11, 2019 at 11:25 AM Ido Schimmel <ido...@idosch.org> wrote: >>> >>> On Fri, Oct 11, 2019 at 09:17:42PM +0300, Ido Schimmel wrote: >>>> On Fri, Oct 11, 2019 at 10:54:13AM -0700, Wei Wang wrote: >>>>> On Fri, Oct 11, 2019 at 8:42 AM Ido Schimmel <ido...@idosch.org> wrote: >>>>>> >>>>>> On Fri, Oct 11, 2019 at 09:36:51AM -0500, Jesse Hathaway wrote: >>>>>>> On Thu, Oct 10, 2019 at 3:31 AM Ido Schimmel <ido...@idosch.org> wrote: >>>>>>>> I think it's working as expected. Here is my theory: >>>>>>>> >>>>>>>> If CPU0 is executing both the route get request and forwarding packets >>>>>>>> through the directly connected interface, then the following can >>>>>>>> happen: >>>>>>>> >>>>>>>> <CPU0, t0> - In process context, per-CPU dst entry cached in the >>>>>>>> nexthop >>>>>>>> is found. Not yet dumped to user space >>>>>>>> >>>>>>>> <Any CPU, t1> - Routes are added / removed, therefore invalidating the >>>>>>>> cache by bumping 'net->ipv4.rt_genid'
IPv4 needs a change similar to what was done for IPv6 - only invalidate dst's for the branches / table affected and not all dst's across the namespace.
