There are (at least) three cases:
1. Discovery is done by odp
2. Discovery is done by application
3. Discovery is done by a third party entity
For cloud, I would expect a cloud administrator entity will know
exactly the configuration of each ‘target’ and this can be provided to
‘target’ as an environment variable or a file.
This information can be used to:
1. Generate an odp.conf file (with a predefine structure),
identifying the module(s) to load.
e.g.
module:
{
modules = ("libodp_thunderx.so.0");
};
2. Download the actual module libs (e.g. from a network drive)
if cannot be deployed with the application (at the same time)
Ultimately, odp.conf stored in a predetermined location or indicated
as an environment variable will be used by odp-core library to load
the module(s).
ODP_SYSCONFIG_FILE=/tmp/odp.conf ./example/generator/odp_generator -I
1 -m r -c 0x8
/Bogdan
On 4 October 2017 at 15:54, Bill Fischofer <bill.fischo...@linaro.org> wrote:
> On Wed, Oct 4, 2017 at 7:47 AM, Savolainen, Petri (Nokia - FI/Espoo) <
> petri.savolai...@nokia.com> wrote:
>
>>
>>
>> > -----Original Message-----
>> > From: Andriy Berestovskyy [mailto:andriy.berestovs...@caviumnetworks.com
>> ]
>> > Sent: Tuesday, October 03, 2017 8:22 PM
>> > To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com>;
>> Ola
>> > Liljedahl <ola.liljed...@linaro.org>; lng-odp@lists.linaro.org
>> > Subject: Re: [lng-odp] generic core + HW specific drivers
>> >
>> > Hey,
>> > Please see below.
>> >
>> > On 03.10.2017 10:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>> > > So, we should be able to deliver ODP as a set of HW independent and
>> > > HW specific packages (libraries). For example, minimal install would
>> > > include only odp, odp-linux and odp-test-suite, but when on arm64
>> > > (and especially when on ThunderX) odp-thunderx would be installed
>> >
>> > There are architecture dependencies (i.e. i386, amd64, arm64 etc), but
>> > there are no specific platform dependencies (i.e. Cavium ThunderX,
>> > Cavium Octeon, NXP etc).
>> >
>> > In other words, there is no such mechanism in packaging to create a
>> > package odp, which will automatically install package odp-thunderx only
>> > on Cavium ThunderX platforms.
>>
>> I'd expect that ODP main package (e.g. for arm64) would run a script
>> (written by us) during install which digs out information about the system
>> and sets up ODP paths accordingly. E.g. libs/headers from odp-thunderx
>> package would added to search paths when installing into a ThunderX system.
>> If system is not recognized, ODP libs/header paths would point into
>> odp-linux.
>>
>>
> That's still trying to make this a static configuration that can be done at
> install time. What about VMs/containers that are instantiated on different
> hosts as they are deployed? This really needs to be determined at run time,
> not install time.
>
>
>>
>> >
>> >
>> > > Package:
>> > > * odp * depends on: odp-linux
>> > > * odp-linux * depends on: odp
>> > > * odp-thunderx [arm64] * depends on: odp
>> >
>> > So installing odp-thunderx we will end up with odp, odp-linux and
>> > odp-thunderx, so still we have switch runtime between odp-linux and
>> > odp-thunderx...
>>
>> I hope it's a matter of probing and installing paths on install time,
>> instead of runtime. It's hard to believe that ODP would be the first
>> package ever to choose and install a library from a set of alternative
>> libraries.
>>
>
> ODP is a pioneer in the sense that it's offering access to platform
> acceleration capabilities, not simple attached device variants. So we may
> well be first in this sense.
>
>
>>
>> >
>> >
>> > All other projects you are mentioning (kernel, DPDK, Xorg) use
>> > architecture dependency (different packages for different architectures)
>> > combined with run time configuration/probing. A kernel driver might be
>> > installed, but it will be unused until configured/probed.
>>
>> Those projects aim to maximize code re-use of the core part and minimize
>> size of the driver part. Optimally, we'd do the opposite - minimize the
>> core part to zero and dynamically link application directly to the right
>> "driver" (== HW specific odp implementation).
>>
>> If there's no core part, run time probing is not needed - install time
>> probing and lib/header path setup is enough.
>>
>
> You're describing the embedded build case, which is similar to what we have
> today with --enable-abi-compat=no. That's not changing. We're only talking
> about what happens for --enable-abi-compat=yes builds.
>
>
>>
>>
>> >
>> > To support multiple platforms, runtime configuration/probing is
>> > inevitable. The real question is who does this probing: ODP itself or
>> > each application independently. To avoid code duplication, ODP looks
>> > like a better choice...
>>
>> Install time probe/conf would be the best choice. The second best would be
>> a dummy "core ODP" implementation which would be just a giant function
>> pointer array (redirect every ODP API call to its implementation in a HW
>> specific lib).
>>
>
> That's effectively what this is, except that the population of that
> indirection array is done at runtime and may vary from run to run based on
> the environment (e.g., is the app running in this container/VM authorized
> to use feature X on this platform? If not, fall back to the generic SW
> implementation, etc.)
>
>
>>
>> -Petri
>>
>>
>>
