> On Nov 10, 2015, at 7:28 AM, Zoltan Kiss <zoltan.k...@linaro.org> wrote:
>
>
>
>> On 10/11/15 15:08, Grant Likely wrote:
>>> On Tue, Nov 10, 2015 at 3:04 PM, Zoltan Kiss <zoltan.k...@linaro.org> wrote:
>>>
>>>
>>>> On 10/11/15 12:04, Grant Likely wrote:
>>>>
>>>> On Tue, Nov 10, 2015 at 11:08 AM, Maxim Uvarov <maxim.uva...@linaro.org>
>>>> wrote:
>>>>>
>>>>>> On 10 November 2015 at 13:41, Zoltan Kiss <zoltan.k...@linaro.org> wrote:
>>>>>>
>>>>>>> On 10/11/15 07:39, Maxim Uvarov wrote:
>>>>>>>
>>>>>>> And it looks like it's problem in OVS, not in ODP. I.e. OVS should
>>>>>>> allow
>>>>>>> to use library functions for fast path (where inlines are critical).
>>>>>>> I.e. not just call odp_packet_len(), but move hole OVS function to
>>>>>>> dynamic library.
>>>>>>
>>>>>>
>>>>>> I'm not sure I get your point here, but OVS allows to use dynamic
>>>>>> library
>>>>>> functions on fast path. The problem is that it's slow, because of the
>>>>>> function call overhead.
>>>>>
>>>>>
>>>>> I'm not familiar with ovs code. But for example ovs has something like:
>>>>>
>>>>> ovs_get_and_packet_process()
>>>>> {
>>>>> // here you use some inlines:
>>>>> pkt = odp_recv();
>>>>> len = odp_packet_len(pkt);
>>>>>
>>>>> ... etc.
>>>>>
>>>>> }
>>>>>
>>>>> So it's clear for each target arch you needs it's own variant of
>>>>> ovs_get_and_packet_process() function. That function should go from ovs
>>>>> to
>>>>> dynamic library.
>>>>
>>>>
>>>> Which library? A library specific to OVS? Or some common ODP library
>>>> that everyone uses? In either case the solution is not scalable. In
>>>> the first case it still requires the app vendor to have a separate
>>>> build for each and every supported target. In the second, it is
>>>> basically argues for all fast-path application-specific code to go
>>>> into a non-app-specific library. That really won't fly.
>>>>
>>>> I have two answers to this question. One for the short term, and one
>>>> for the long.
>>>>
>>>> In the short term we have no choice. If we're going to support
>>>> portable application binaries, then we cannot do inlines. ODP simply
>>>> isn't set up to support that. Portable binaries will have to take the
>>>> hit of doing a function call each and every time. It's not fast, but
>>>> it *works*, which at least will set a lowest common denominator. To
>>>> mitigate the problem we could encourage application packages to
>>>> include a generic version (no-inlines, but works everywhere) plus one
>>>> or more optimized builds (with inlines) and the correct binary is
>>>> selected at runtime. Not great, but it is a reasonable answer for the
>>>> short term.
>>>
>>>
>>> I would argue for the short term to produce platform specific packages as
>>> well, at least for ODP-OVS. As ODP-OVS is not upstream, we need to produce
>>> an openvswitch-odp package anyway (which would set to conflict with the
>>> normal openvswitch package). My idea is to create openvswitch-odp-[platform]
>>> packages, though I don't know if you can set a wildcard conflict rule during
>>> packaging to make sure only one of them are installed at a time.
>>>
>>>>
>>>> For the long term to get away from per-platform builds, I see two
>>>> viable options. Bill suggested the first: Use LLVM to optimize at
>>>> runtime so that thing like inlines get picked up when linked to the
>>>> platform library. There is some precedence of other projects already
>>>> doing this, so this isn't as far fetched as it may seem.
>>>
>>>
>>> But wouldn't it tie us down with LLVM?
>>
>> Does that worry you?
>
> Only that then we require our applications to use LLVM if they want
> performance. I don't know the impact of that.
Or they recompile the programs to get the speed. I am sorry but this is not a
new problem. Most of the embedded folks are use to this. What a vendor of odp
could do is provide an optimized version of the programs they think are
important.
Thanks,
Andrew
>
>> LLVM is a mature project, open source, and lots
>> of momentum behind it. There are worse things we can do than align
>> with LLVM when it brings capability that we cannot get anywhere else.
>>
>> g.
> _______________________________________________
> linaro-toolchain mailing list
> linaro-toolchain@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-toolchain
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
