User Tools

Site Tools


dpacc:dpacc_work_item_framework_arc

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
dpacc:dpacc_work_item_framework_arc [2015/05/18 07:38]
Lingli Deng
dpacc:dpacc_work_item_framework_arc [2016/01/28 07:38] (current)
Lingli Deng
Line 1: Line 1:
-====== ​Current ​High Level Architecture Overview ======+====== High Level Architecture Overview ======
  
-Power point file is [[:dpacc:​opnfv-dapcc-mini-summit.v11.pptx|Here]]+Earlier presentation {{dpacc:​opnfv-dapcc-mini-summit.v11.pptx|Here}}
  
-{{:dpacc:​dpacc-phases.png?​2048|}} +Work in progress [[https://docs.google.com/​document/​d/​1O4rtCh1vbTOO5cMwmRwfv3UJb_bVWZrqXQS_-QJAk10/edit|Here]]
-{{:​dpacc:​dpacc-goals.png?​2048|}} +
-{{:​dpacc:​all-sal-guest-vm.png?​2048|}} +
-{{:​dpacc:​all-sal-host.png?​2048|}} +
-{{:​dpacc:​all-sal-options.png?​2048|}} +
-{{:​dpacc:​nfv-high-level-view.png?​2048|}} +
-{{:​dpacc:​dpacc-summary.png?​2048|}}+
  
-====== DPACC High Level Requirements:​ ====== 
-[Note] This is only a place holder for requirement documentation. ​ 
-Current drafting and discussion is done here: https://​etherpad.opnfv.org/​p/​dpacc_high_level_requirements 
- 
-  - The DPACC design must be as high a performing design as possible 
-  - The DPACC design must proved portability for the applications 
-  - The DPACC design must be scalability in performance and design 
-  - All code within the DPACC design must be open sourced with a BSD or MIT like license 
-    - The DPACC design must not contain or require proprietary code 
-    - The code can not be in binary form and must be in source code form 
-      - The only excepted binary form allowed would be firmware that is loaded in the device 
-  - The DPACC can not use non-upstreamed kernel modules or modifications 
-    - The DPACC design can not allow the host kernel to crash by adding a module or kernel modification 
- 
-===== g-API: High Level Requirements ===== 
- 
- 
-  - The API is for the application portability 
-    - The applications should not be required to modify the application to follow this API 
-      - One example is the current install base of DPDK applications needs to be maintained without require re-writes. 
-  - Written in a portable language 
-    - '​C'​ is the most common 
-  - Allow for the best performance of the underlying s-API or Acceleration Core. 
-    - Which means to me a very thin layer on top of the s-API to not effect native Acceleration Core performance 
-  - API must be documented 
-    - Do we want Doygen with inline code comments for documenting the API? 
-  - All code must be open source using a BSD or MIT like license 
- 
-===== legacy-API: High Level Requirements ===== 
- 
- 
- 
-  - Must follow the standard legacy APIs as close as possible 
-  - API is for legacy applications portability 
-  - Written in a port language like C 
-  - Support a reasonable set of API types sockets, libcrypto, ... 
-  - API must be documented if any differences from the native API 
-  - All code must be open source using a BSD or MIT like license 
- 
-===== SIO: High Level Requirement ===== 
- 
- 
-  - Need to determine if we need any requirements here 
  
 +====== DPACC High Level Requirements ======
  
 +Work-in-progress [[https://​docs.google.com/​document/​d/​1Bg3jGOiE5HIfrRE9cv-r6EIABjO9pPJC1bEKDN375YE/​edit|here]]
dpacc/dpacc_work_item_framework_arc.1431934703.txt.gz · Last modified: 2015/05/18 07:38 by Lingli Deng