Session ID: SFO17-303 Session Name: A Modular Framework for Componentization - SFO17-303 Speaker: Yi He Track: LNG ★ Session Summary ★ This talk presents a highly flexible framework being developed to support ODP for NFV environments. The framework permits dynamic pluggable components that can be personalized to microarchitectural differences discovered at runtime while still supporting application binary compatibility across an Instruction Set Architecture (ISA) as well as static bindings suitable for deep embedded use. --------------------------------------------------- ★ Resources ★ Event Page: http://connect.linaro.org/resource/sfo17/sfo17-303/ Presentation: Video: --------------------------------------------------- ★ Event Details ★ Linaro Connect San Francisco 2017 (SFO17) 25-29 September 2017 Hyatt Regency San Francisco Airport --------------------------------------------------- Keyword: http://www.linaro.org http://connect.linaro.org --------------------------------------------------- Follow us on Social Media https://www.facebook.com/LinaroOrg https://twitter.com/linaroorg https://www.youtube.com/user/linaroorg?sub_confirmation=1 https://www.linkedin.com/company/1026961

1. SFO17-303: A Modular Framework for
Componentization
Yi He
Staff Software Engineer, Arm
(yi.he@linaro.org, yi.he@arm.com)

2. ENGINEERS AND DEVICES
WORKING TOGETHER
Agenda
● Motivation
● Benefits
● How to Use
● Next Steps

3. ENGINEERS AND DEVICES
WORKING TOGETHER
Motivation
● Extensible and modularize implementations (drivers) of
packet I/O interface, allow build and run time selection.
● Derived from ODP Device and Driver Framework

4. ENGINEERS AND DEVICES
WORKING TOGETHER
Extend the Scope
● This approach can extend to wider ODP APIs subsets.
● Has been introduced into ODP project and experiment
applying to multiple software components: cloud-dev

5. ENGINEERS AND DEVICES
WORKING TOGETHER
Possibilities
● ODP APIs can be partitioned into multiple subsets (called
subsystems)
○ Encourage API polishing, abstraction and programming model
design improvement per subsystem
● Each API subset can have multiple impls (called modules)
○ Encourage variant impls to be hosted in ODP project repository
in either binary or source form
● ODP APIs can be extended by adding new subsystems
○ Encourage differentiation, convert ODP into an extensible
framework for unifying programming APIs

6. ENGINEERS AND DEVICES
WORKING TOGETHER
Modular Programming Framework
● Decouple implementations from software interface
● Write each implementation as a module
● Use cases:
○ Select implementation modules in build time (linking)
○ Select implementation modules in run time (dynamic loading)
○ Select one implementation and replace the API stubs to
eliminate API route overhead*
● Advantage of using modular framework:
○ No source code changes for implementation modules to
support all above use cases
● Demo: https://github.com/heyi-linaro/pure-interface

7. ENGINEERS AND DEVICES
WORKING TOGETHER
Software Interface Declaration

8. ENGINEERS AND DEVICES
WORKING TOGETHER
Implementation as Module

9. ENGINEERS AND DEVICES
WORKING TOGETHER
Software Interface Stub - 1
● Route the API call to the default (active) module

10. ENGINEERS AND DEVICES
WORKING TOGETHER
Software Interface Stub - 2
● Iterate the API call through all modules

11. ENGINEERS AND DEVICES
WORKING TOGETHER
Select Modules in Build Time
● Such as built-in drivers which are always enabled in build
time, e.g. loopback packet I/O
● Static Linking:
○ -Wl,--whole-archive <modules-list> -Wl,--no-whole-archive
● Dynamic Linking:
○ -Wl,--no-as-needed <modules-list> -Wl,--as-needed
● Demo, make targets:
○ main-static
○ main-dynamic

12. ENGINEERS AND DEVICES
WORKING TOGETHER
Select Modules in Run Time
● Build modules as Dynamic Shared Objects (DSOs)
● Write a module loader to load modules dynamically,
according to config file, CLI options or platform probing
● Demo, make target:
○ main-plugin

13. ENGINEERS AND DEVICES
WORKING TOGETHER
Dynamic Module Loader

14. ENGINEERS AND DEVICES
WORKING TOGETHER
API Stubs Override
● When one implementation only, need to eliminate the API
stub overhead
● Prepare a header file to declare the API stub override and
include it in Makefile to change module building rule
default-scheduler.o: default-scheduler.c default-scheduler-override.h
$(CC) $(CFLAGS) -include “default-schduler-override.h" -c -o $@ $<
● Demo, make target:
○ main-static-override
○ main-preload (with override DSOs)

15. ENGINEERS AND DEVICES
WORKING TOGETHER
API Stubs Override

16. ENGINEERS AND DEVICES
WORKING TOGETHER
Next Steps
● Adopt Modular Framework in ODP
● Code auto-generation with Modular Framework

17. Thank You, Q & A
Contact: yi.he@linaro.org, yi.he@arm.com
#SFO17
SFO17 keynotes and videos on: connect.linaro.org
For further information: www.linaro.org