On 5 October 2017 at 12:09, Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com> wrote: > No HTML mails, please. > > > From: Bill Fischofer [mailto:bill.fischo...@linaro.org] > Sent: Wednesday, October 04, 2017 3:55 PM > To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com> > Cc: Andriy Berestovskyy <andriy.berestovs...@caviumnetworks.com>; Ola > Liljedahl <ola.liljed...@linaro.org>; lng-odp@lists.linaro.org > Subject: Re: [lng-odp] generic core + HW specific drivers > > > > On Wed, Oct 4, 2017 at 7:47 AM, Savolainen, Petri (Nokia - FI/Espoo) > <mailto:petri.savolai...@nokia.com> wrote: > > >> -----Original Message----- >> From: Andriy Berestovskyy >> [mailto:mailto:andriy.berestovs...@caviumnetworks.com] >> Sent: Tuesday, October 03, 2017 8:22 PM >> To: Savolainen, Petri (Nokia - FI/Espoo) >> <mailto:petri.savolai...@nokia.com>; Ola >> Liljedahl <mailto:ola.liljed...@linaro.org>; mailto: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. > > > > Also with a VM, all arm64 ODP packages would be present, and the problem to > solve would be which implementation to use (to link against). If a run time > code can probe the host system (e.g. are we on ThunderX), so does a script. > An ignorant user might not run additional scripts and thus be left with the > default setup (odp-linux). A more aware user would run an additional script > before launching/building any ODP apps. This script would notice that we have > e.g. ThunderX HW and would change ODP paths to point into odp-thunderx > libs/headers. The HW discovery could be as simple as cloud administrator > updating VM bootparams with SoC model information. > > >> >> 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. > > > > No, I'm pointing that the more there's common core SW, the more there are > trade-offs and the less direct HW access == less performance. For optimal > performance, the amount of common core SW is zero. Yes this is sort of the ideal but I doubt this type of installation will be accepted by e.g. Red Hat for inclusion in server-oriented Linux distributions. Jon Masters seems to be strongly against this (although I have only heard this second hand). So that's why I proposed the common (generic) core + platform specific drivers model that is used by e.g. Xorg and DPDK. Since DPDK is actually a user space framework (unlike Xorg), this should be a good model for ODP and something that Red Hat cannot object against.
> > You may very well want to build and run non-ABI compat applications also in a > VM. Non-ABI compat just means that you are not going to run *the same > application image* with another implementation/system. You may still build > locally on the VM, or have bunch of (non-ABI compat) application images > pre-built - one per implementation/system. > > >> >> 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.) > > > > I'm saying that the second option is that we do not define a common core > implementation / module framework / etc, but just a big and dummy function > pointer structure which maps each and every ODP API call directly to the HW > specific implementation of it (1:1 mapping, no code re-use and trade-offs > between implementations, second best performance after direct linking). > > > -Petri >
