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