On Thu, Jul 7, 2016 at 5:23 PM, Pravin B Shelar <pshe...@ovn.org> wrote: > This backports dst-cache implementation from upstream implementation. > > commit 911362c70df5b766c243dc297fadeaced786ffd8 > Author: Paolo Abeni <pab...@redhat.com> > > net: add dst_cache support > This patch add a generic, lockless dst cache implementation. > The need for lock is avoided updating the dst cache fields > only in per cpu scope, and requiring that the cache manipulation > functions are invoked with the local bh disabled. > > The refresh_ts and reset_ts fields are used to ensure the cache > consistency in case of cuncurrent cache update (dst_cache_set*) and > reset operation (dst_cache_reset). > > Consider the following scenario: > > CPU1: CPU2: > <cache lookup with emtpy cache: it fails> > <get dst via uncached route lookup> > <related configuration > changes> > dst_cache_reset() > dst_cache_set() > > The dst entry set passed to dst_cache_set() should not be used > for later dst cache lookup, because it's obtained using old > configuration values. > > Since the refresh_ts is updated only on dst_cache lookup, the > cached value in the above scenario will be discarded on the next > lookup. > > Signed-off-by: Paolo Abeni <pab...@redhat.com> > Suggested-and-acked-by: Hannes Frederic Sowa <han...@stressinduktion.org> > Signed-off-by: David S. Miller <da...@davemloft.net> > > Signed-off-by: Pravin B Shelar <pshe...@ovn.org> > Acked-by: Jesse Gross <je...@kernel.org>
I saw in the big Geneve/VXLAN backport patch that USE_UPSTREAM_TUNNEL becomes dependent on having the dst cache. That's fine but I couldn't find anywhere that prevents the reverse - continuing to use our version of the dst cache when we have upstream tunnels (the functions here look like unconditional replacements). It seems like that will create a problem in a couple weeks when 4.7 is released. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
