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
