On Wed, Jul 6, 2016 at 3:44 PM, pravin shelar <pshe...@ovn.org> wrote: > On Tue, Jul 5, 2016 at 6:54 PM, Jesse Gross <je...@kernel.org> wrote: >> On Fri, Jul 1, 2016 at 5:58 PM, Pravin B Shelar <pshe...@ovn.org> wrote: >>> diff --git a/acinclude.m4 b/acinclude.m4 >>> index 263c31d..05b5f48 100644 >>> --- a/acinclude.m4 >>> +++ b/acinclude.m4 >>> @@ -556,6 +556,7 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [ >>> >>> OVS_GREP_IFELSE([$KSRC/include/net/dst.h], [dst_discard_sk]) >>> OVS_GREP_IFELSE([$KSRC/include/net/dst.h], [__skb_dst_copy]) >>> + OVS_GREP_IFELSE([$KSRC/include/net/dst_cache.h], [dst_cache]) >> >> Looking at this some more, is the symbol created by this check >> actually used anywhere? Unless I am missing something, it seems like >> we unconditionally replace the dst cache with ours. >> >> It seems to me that we might want to make the use of the dst cache >> follow whether we are using upstream tunnels or not. If the upstream >> dst cache is available then it should be fine to use that with the OVS >> tunnel implementation as well. However, if we end up using upstream >> tunnels and the OVS dst cache (because of inconsistent backports) then >> that probably won't work very well. > > I added DST_CACHE to detect dat_cache support in kernel, but since > none of supported kernel has it, I could not test the use of the > symbol correctly. Therefore I have decided to remove the symbol for > now. we can introduce it when we add support for newer kernel.
I think it may be best to use !USE_UPSTREAM_TUNNEL, especially if we remove the dst cache feature check. Otherwise, there's a good chance that we might end up trying to use our dst cache with the upstream tunnel code, which won't work. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev