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