On 3 October 2017 at 07:59, Bill Fischofer <bill.fischo...@linaro.org> wrote: > Good summary. The key is that RedHat and others want: > > 1. They build the distribution from source we provide, we don't get to > provide any binaries > 2. There is a single distribution they will support per-ISA (e.g., AArch64) > > The modular framework is designed to accommodate these requirements by > allowing a "universal core" to discover the microarchitecture at run time > and the most appropriate pluggable modules to use to exploit that > microarchitecture's acceleration capabilities. These modules may be > precompiled along with the core if they are part of the single ODP > distribution, or they may be packaged and distributed separately as the > supplier of these modules wishes. > > At the same time, this universal core can be statically linked for a > specific target platform to accommodate the needs of embedded applications. > In this case the discovery and call-indirection goes away so there should > be no more overhead than exists in today's ODP when switching between > --enable-abi-compat=[yes|no]
Agree. We are currently looking into how the inline functions can be enabled when building for a specific target platform. > > On Tue, Oct 3, 2017 at 5:12 AM, Francois Ozog <francois.o...@linaro.org> > wrote: > >> Thanks Ola and Petri. >> >> Let's talk about use cases first. >> >> Go to market for ODP applications may be: >> >> - A product composed of software and hardware (typically a NEP approach >> such as Nokia) >> - A software to be installed by a system administrator of an enterprise >> - A "service" to be part of a cloud offering (say an AWS image) >> - A VNF to be deployed on a wide variety, apriori unknown, of hardware >> as a VM >> - An image to be deployed on bare metal clouds (packet.net or OVH for >> instance) with hardware diversity >> >> As a result, an ODP application may be : >> >> 1. Deployed as a single installed image and instantiated in different >> virtualized or bare metal clouds >> 2. A VM is live migrated between two asymetric compute nodes >> 3. Installed on a specific machine >> 4. Deployed as an image that is to be instantiated on a single hardware >> platform >> >> Irrespective of commercial Linux distribution acceptance, case 3 and 4 can >> accommodate a static deployment paradigm where the hardware dependent >> package is selected at installation time. Those cases corresponds to a >> system integrator, an network equipment provider that builds a product for >> a specific hardware platform. >> >> On the other hand, case 1 and 2 need a run time adaptation of the >> framework. Case 2 may in fact be more between platform of the same type but >> with different PLUGGED NICs and accelerators. While technically feasible >> (yet very complex), I don't expect to deal with live migration between >> Cavium and NXP or even Cavium ThunderX and Cavium ThunderX/2. >> So case 1 is essentially addressing the needs of ISVs that do NOT sell a >> bundle of software and hardware as a product. You can call it software >> appliance. >> >> Ola, on the Xorg thing: yes it says that xorg.conf is now determined at >> runtime... But if you concretely experience changing graphics card, or >> supporting both CPU integrated graphics in additional to external GPU, you >> will face trouble and find a lot of literature about achieving the results >> or recovering from depressive situations... >> >> >> The modular framework allows one ODP implementation to be considered as a >> single module and loaded at runtime to solve case 1, 3 and 4. Those modules >> may still be deployed as separate packages. The initial idea was to split >> the implementation in more modules but it may not make that much sense >> after giving more thoughts. Additional native drivers and the DDF itself >> may be considered as separate modules and also distributed as separate >> packages. >> So we would have: >> - odp-core >> - odp-linux required module that provides AF packet and other packetios; >> depends on odp-core >> - odp-ddf optional module that provides dynamic pluggable hardware support; >> depends on odp-core >> - odp-<NIC> optional modules for the various native NIC support; depends on >> odp-ddf >> - odp-<platform> optional modules to deal with SoC specific arch (ThunderX, >> ThunderX/2, DPAA2...); depends on odp-core >> >> The odp-<platform> is derived from the current native SoC implementation >> but need to leverage odp-mbuf and the new mempool facilities to allow >> diversity of packetio to livetogether in a single platform, the rest is >> entirely proprietary. >> >> The static and dynamic approaches are not mutually exclusive. I highly >> recommend that the static (case 3 and 4) approach is driven by individual >> members should they need it while we collectively solve the broader cloud >> (case 1) deployment. >> >> Cheers >> >> FF >> >> On 3 October 2017 at 10:12, Savolainen, Petri (Nokia - FI/Espoo) < >> petri.savolai...@nokia.com> wrote: >> >> > > -----Original Message----- >> > > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of >> Ola >> > > Liljedahl >> > > Sent: Friday, September 29, 2017 8:47 PM >> > > To: lng-odp@lists.linaro.org >> > > Subject: [lng-odp] generic core + HW specific drivers >> > > >> > > olli@vubuntu:~$ dpkg --get-selections | grep xorg >> > > xorg install >> > > xorg-docs-core install >> > > xserver-xorg install >> > > xserver-xorg-core install >> > > xserver-xorg-input-all install >> > > xserver-xorg-input-evdev install >> > > xserver-xorg-input-libinput install >> > > xserver-xorg-input-synaptics install >> > > xserver-xorg-input-wacom install >> > > xserver-xorg-video-all install >> > > xserver-xorg-video-amdgpu install >> > > xserver-xorg-video-ati install >> > > xserver-xorg-video-fbdev install >> > > xserver-xorg-video-intel install >> > > xserver-xorg-video-mach64 install >> > > xserver-xorg-video-neomagic install >> > > xserver-xorg-video-nouveau install <<<Nvidia >> > > xserver-xorg-video-openchrome install >> > > xserver-xorg-video-qxl install >> > > xserver-xorg-video-r128 install >> > > xserver-xorg-video-radeon install . <<<AMD >> > > xserver-xorg-video-savage install >> > > xserver-xorg-video-siliconmotion install >> > > xserver-xorg-video-sisusb install >> > > xserver-xorg-video-tdfx install >> > > xserver-xorg-video-trident install >> > > xserver-xorg-video-vesa install >> > > xserver-xorg-video-vmware install . <<<virtualised GPU? >> > > >> > > So let's rename ODP Cloud to ODP Core. >> > > >> > > -- Ola >> > >> > >> > DPDK packages in Ubuntu 17.05 (https://packages.ubuntu.com/artful/dpdk) >> > include many HW dependent packages >> > >> > ... >> > librte-pmd-fm10k17.05 (= 17.05.2-0ubuntu1) [amd64, i386] <<< Intel Red >> > Rock Canyon net driver, provided only for x86 >> > librte-pmd-i40e17.05 (= 17.05.2-0ubuntu1) >> > librte-pmd-ixgbe17.05 (= 17.05.2-0ubuntu1) [not ppc64el] >> > librte-pmd-kni17.05 (= 17.05.2-0ubuntu1) [not i386] >> > librte-pmd-lio17.05 (= 17.05.2-0ubuntu1) >> > librte-pmd-nfp17.05 (= 17.05.2-0ubuntu1) >> > librte-pmd-null-crypto17.05 (= 17.05.2-0ubuntu1) >> > librte-pmd-null17.05 (= 17.05.2-0ubuntu1) >> > librte-pmd-octeontx-ssovf17.05 (= 17.05.2-0ubuntu1) <<< OcteonTX SSO >> > eventdev driver files as a package >> > librte-pmd-pcap17.05 (= 17.05.2-0ubuntu1) >> > librte-pmd-qede17.05 (= 17.05.2-0ubuntu1) >> > librte-pmd-ring17.05 (= 17.05.2-0ubuntu1) >> > librte-pmd-sfc-efx17.05 (= 17.05.2-0ubuntu1) [amd64] >> > librte-pmd-skeleton-event17.05 (= 17.05.2-0ubuntu1) >> > librte-pmd-sw-event17.05 (= 17.05.2-0ubuntu1) >> > librte-pmd-tap17.05 (= 17.05.2-0ubuntu1) >> > librte-pmd-thunderx-nicvf17.05 (= 17.05.2-0ubuntu1) <<< ThunderX net >> > driver files as a package >> > ... >> > >> > >> > 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 also. The trick would >> be >> > how to select odp-thunderx installed files (also headers) as default when >> > application is built or run on ThunderX (and not on another arm64). >> > >> > Package: >> > * odp (only generic folders and documentation, no implementation) >> > * depends on: odp-linux, odp-test-suite >> > * recommends: odp-linux, odp-dpdk, odp-thunderx, odp-dpaa2, ... >> > * odp-linux >> > * depends on: odp, openssl >> > * recommends: dpdk, netmap, ... >> > * odp-dpdk >> > * depends on: odp, dpdk >> > * odp-thunderx [arm64] >> > * depends on: odp, ... >> > * odp-test-suite >> > * depends on: odp >> > >> > >> > -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 >>
