[ovs-dev] [PATCH v3 04/28] datapath: backport: net: add dst_cache support

[Jesse Gross]

On Wed, Jul 6, 2016 at 3:44 PM, pravin shelar <pshelar at ovn.org> wrote:
> On Tue, Jul 5, 2016 at 6:54 PM, Jesse Gross <jesse at kernel.org> wrote:
>> On Fri, Jul 1, 2016 at 5:58 PM, Pravin B Shelar <pshelar at 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.