This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
dpacc:dpacc_work_item_framework_arc [2015/05/15 19:25] Keith Wiles |
dpacc:dpacc_work_item_framework_arc [2016/01/28 07:38] (current) Lingli Deng |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== DPACC High Level Requirements: ====== | + | ====== High Level Architecture Overview ====== |
- | - The DPACC design must be as high a performing design as possible | + | Earlier presentation {{dpacc:opnfv-dapcc-mini-summit.v11.pptx|Here}} |
- | - 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 ====== | + | Work in progress [[https://docs.google.com/document/d/1O4rtCh1vbTOO5cMwmRwfv3UJb_bVWZrqXQS_-QJAk10/edit|Here]] |
- | - 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 ====== | + | ====== DPACC High Level Requirements ====== |
- | - Must follow the standard legacy APIs as close as possible | + | Work-in-progress [[https://docs.google.com/document/d/1Bg3jGOiE5HIfrRE9cv-r6EIABjO9pPJC1bEKDN375YE/edit|here]] |
- | - 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 | + | |
- | + | ||
- | ====== Current High Level Overview ====== | + | |
- | + | ||
- | Power point file is [[:dpacc:opnfv-dapcc-mini-summit.v11.pptx|Here]] | + | |
- | + | ||
- | {{:dpacc:sal-guest-vm.png?600|}} | + |