Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A Modular Framework for Componentization - SFO17-303

153 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

A Modular Framework for Componentization - SFO17-303

  1. 1. SFO17-303: A Modular Framework for Componentization Yi He Staff Software Engineer, Arm (yi.he@linaro.org, yi.he@arm.com)
  2. 2. ENGINEERS AND DEVICES WORKING TOGETHER Agenda ● Motivation ● Benefits ● How to Use ● Next Steps
  3. 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. 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. 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. 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. 7. ENGINEERS AND DEVICES WORKING TOGETHER Software Interface Declaration
  8. 8. ENGINEERS AND DEVICES WORKING TOGETHER Implementation as Module
  9. 9. ENGINEERS AND DEVICES WORKING TOGETHER Software Interface Stub - 1 ● Route the API call to the default (active) module
  10. 10. ENGINEERS AND DEVICES WORKING TOGETHER Software Interface Stub - 2 ● Iterate the API call through all modules
  11. 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. 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. 13. ENGINEERS AND DEVICES WORKING TOGETHER Dynamic Module Loader
  14. 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. 15. ENGINEERS AND DEVICES WORKING TOGETHER API Stubs Override
  16. 16. ENGINEERS AND DEVICES WORKING TOGETHER Next Steps ● Adopt Modular Framework in ODP ● Code auto-generation with Modular Framework
  17. 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

×