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? 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
