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?
The second is
to do what we already do in the kernel for ftrace: instrument the
function calls and runtime patch them with optimized inlines. Not
pretty, probably fragile, but we do have the knowledge from the kernel
Yes, I was thinking also about the ftrace way, but I'm not familiar with
ld.so enough to judge how hard it would be.
of how to do it. All said, I would prefer an LLVM based solution, but
investigation is needed to figure out how to make it work.
g.
On 10 November 2015 at 02:50, Bill Fischofer <bill.fischo...@linaro.org
<mailto:bill.fischo...@linaro.org>> wrote:
Adding Grant Likely to this chain as it relates to the broader
subject of portable ABIs that we've been discussing.
On Mon, Nov 9, 2015 at 4:48 PM, Jim Wilson <jim.wil...@linaro.org
<mailto:jim.wil...@linaro.org>> wrote:
On Mon, Nov 9, 2015 at 2:39 PM, Bill Fischofer
<bill.fischo...@linaro.org <mailto:bill.fischo...@linaro.org>>
wrote:
> The IO Visor project appears to be doing something like this
with LLVM and
> JIT constructs to dynamically insert code into the kernel in a
> platform-independent manner. Perhaps we can leverage that
technology?
GCC has some experimental JIT support, but I think it would be a
lot
of work to use it, and I don't know how stable it is.
https://gcc.gnu.org/wiki/JIT
The LLVM support is probably more advanced.
Jim
_______________________________________________
lng-odp mailing list
lng-...@lists.linaro.org <mailto:lng-...@lists.linaro.org>
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
lng-...@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
lng-...@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
