Bob Monkman commented on about 'platform discovery' during my talk at
Connect. His thought is that with Intel EPA and such (enhanced
platform awareness), the orchestrater will have in-depth data about
the platform. It will have information about the make and model of a
NIC/hardware accelerator for ex:. He promised to provide few
documents, I am following up.
Thanks,
Honnappa
On 4 October 2017 at 08:46, Francois Ozog <francois.o...@linaro.org> wrote:
> Hi Bogdan,
>
> cloud manager is a loosely defined entity ;-)
>
> In the context of NFV orchestration will not deal with this.
>
> VNF manager may but there is lack of "sensing" information.
>
> If you think of an AWS/Azure image, then this simply does not work.
>
> FF
>
> On 4 October 2017 at 15:27, Bogdan Pricope <bogdan.pric...@linaro.org>
> wrote:
>
>> 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.Berestovskyy@
>> 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
>> >>
>> >>
>> >>
>>
>
>
>
> --
> [image: Linaro] <http://www.linaro.org/>
> François-Frédéric Ozog | *Director Linaro Networking Group*
> T: +33.67221.6485
> francois.o...@linaro.org | Skype: ffozog
