User Tools

Site Tools


dpacc:minutes20160226

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:minutes20160226 [2016/02/26 08:34]
Lingli Deng [follow-up actions]
dpacc:minutes20160226 [2016/02/29 09:57] (current)
Lingli Deng [g-api guidelines discussion]
Line 6: Line 6:
  
 ====== Attendants ====== ====== Attendants ======
-Lingli, Keith, Yannan, Denis, Rajesh, Howard, Barat, Mario+Lingli, Keith, Yannan, Denis, Rajesh, Howard, Barat, Ola, Mario, Paul, Michele, Trinath, Jesper
  
 ====== Arch doc update review ====== ====== Arch doc update review ======
Line 15: Line 15:
  
  
-===== Agreed? ​Mandate SAL to DPACC Architecture =====+===== Mandate SAL to DPACC Architecture =====
  
 Instead of mandating AC, the proposed updated doc mandates SAL as required. Instead of mandating AC, the proposed updated doc mandates SAL as required.
Line 21: Line 21:
  
 //SAL is the software to hardware abstraction layer, which makes possible additional services which can be controlled by the orchestration layer. SAL can be deployed to either guest or host. SAL is required in all DPACC usages identified in this document.// //SAL is the software to hardware abstraction layer, which makes possible additional services which can be controlled by the orchestration layer. SAL can be deployed to either guest or host. SAL is required in all DPACC usages identified in this document.//
 +
 +Agreed.
  
 ===== Usage Types and Examples ===== ===== Usage Types and Examples =====
  
 Changes are proposed to both the figures and the text in Section 2.2.1 and 2.2.2, in order to clarify the correspondence between these two parts. The proposal is to use Section 2.2.1 to identify two usage types, each of which is with options and can be further instantiated with several usage examples. Some of the examples of the two usage types are illustrated in the following Section 2.2.2. But the intention is not to change what we have already agreed on for the usage examples. Changes are proposed to both the figures and the text in Section 2.2.1 and 2.2.2, in order to clarify the correspondence between these two parts. The proposal is to use Section 2.2.1 to identify two usage types, each of which is with options and can be further instantiated with several usage examples. Some of the examples of the two usage types are illustrated in the following Section 2.2.2. But the intention is not to change what we have already agreed on for the usage examples.
 +
 +Need more review and feedback offline.
  
 ===== Follow Up Actions ===== ===== Follow Up Actions =====
Line 38: Line 42:
  
 Yannan refined the figure of the LTE stack, according to Vineet'​ comment to differentiate the control plane and data plane towards S1 interface. ​ Yannan refined the figure of the LTE stack, according to Vineet'​ comment to differentiate the control plane and data plane towards S1 interface. ​
-Keith suggested adding terminology section and define the wireless terms in this figure. ​Yannan could help with the wireless terms.+Keith suggested adding terminology section and define the wireless terms in this figure. ​ 
 +Ola suggested to change "S1 User Plane" into "raw traffic"​ in the figure, and consider the integration of another application of IPSec tunneling between vRAN and vEPC.
  
 +Offline discussion need for figure revision.
 +Yannan could help with adding definitions of the wireless terms.
 ===== Figures update and discussion ===== ===== Figures update and discussion =====
  
Line 50: Line 57:
 ===== Follow-up actions ===== ===== Follow-up actions =====
  
-  - Figure update: Denis would update ipsec-la and Rajesh would update pdcp-la figures in Section 5.+  - Figure update: Denis would update ipsec-la and Rajesh would update pdcp-la figures in Section 5. Lingli, Yannan and Ola would discuss offline on LTE figure revision.
   - RAN Terminology:​ Yannan would help add definitions for RAN terms in Terminology Section.   - RAN Terminology:​ Yannan would help add definitions for RAN terms in Terminology Section.
  
Line 66: Line 73:
 Automatic detection and recovery of faulty agent (MAY) Automatic detection and recovery of faulty agent (MAY)
 Fault Analysis or Problem Diagnosis for acceleration resources (MAY) Fault Analysis or Problem Diagnosis for acceleration resources (MAY)
- 
 Gaps are to be added next week after the consensus on the requirements statement. Gaps are to be added next week after the consensus on the requirements statement.
 +
 +Agreed.
 ===== Metadata Table Removed ===== ===== Metadata Table Removed =====
 The metedata example table is suggested to be removed from the doc, and serve as the basis for a separate discussion thread dedicated to DPACC metadata to be started next week. The metedata example table is suggested to be removed from the doc, and serve as the basis for a separate discussion thread dedicated to DPACC metadata to be started next week.
 +
 +Agreed.
 ===== Follow Up Actions ===== ===== Follow Up Actions =====
  
Line 84: Line 94:
  
  
-====== ​common ​g-api discussion ======+====== g-api guidelines ​discussion ======
  
-       * {{:dpacc:opnfv-discuss-common-gapi-20160219.pptx|common gapi discussion}}+       * {{:dpacc:g-api_guidelines_discussion-20160225.pptx|discussion ​slides}} 
 +       * {{:​dpacc:​dpacc_api_guidelines_1.0-dll.docx|latest proposal draft}} 
 +       * {{:​dpacc:​api_guidelines_01.pdf|earlier proposal draft}}
  
-===== common g-api analysis for virtio-pdcp and virtio-ipsec ===== 
  
-  * Rajesh presented the management APIs respectively ​for virtio-pdcp and virtio-ipsec proposals, and identified three “common” APIswhich share the same generic functionalities but different in specific parameters. The suggestion ​is not to try to design ​another ​layer of common APIs for different usecasesas they differ fundamentally in the control/​data format to be conveyed.  +Denis and Rajesh presented the proposal of specifying common guidelines ​for various DPACC usecases, including suggestions on basic types, api/​variable naming convention, function structure, and return values.  
-  Lingli clarified the vision was actually a guidelines ​for virtio-xxx spec/​proposalwhich contains basic functionality ​description of the high level APIs (which could be instantiated by specific ​APIs in each usecase) but shared ​the same design philosophy or pattern+ 
-  Rajesh agreed ​to have the common design patterns ​for the g-API’s instead ​of common ​API’s, and made an initial contribution based on Subha and Srini’s earlier proposalhttps://​wiki.opnfv.org/​_media/​dpacc/​api_guidelines_01.pdf +Keith raised the question on the closed box approach would not work for open sourceLingli clarified that the position of this work is not to regulate the practice but serve as experience sharing from existing implementations ​to be shared with subsequent endeavors. 
 + 
 +Agreed to start the work, Lingli would compose ​another ​Google doc for later collaboration. ​  
 + 
 +Discussion went on to the proposal details (some of the suggestions from Keith) 
 +    * for naming convention, the acceleration model can be used as a parameter rather than part of the API name 
 +    * for common operations, one may use SET for MOD, so no need for MOD. Do not mandate that all implementations would support any common operations, like OPEN or CLOSE
 +    * for errcode definitions,​  
 +      * Keith suggested to use the errcode to identify the responsive module (assigned when it gets integrated with the framework) as well as the actual err conditions (might be further defined within the responsive module). Take 32-bit errcode for examplethe first 16 bits can be used as the ID for the accelerator ​functionality, and the second 16 bits can be used as the actual errcodes for that specific ​accelerator. Ola was concerned about how to implement management for allocating ​the IDs for different modules/​accelerators from different parties. Lingli suggested to specify the rules/keep a registry in this intended DPACC document
 +      Ola suggested that it does not make much sense to define +ve codes for success. Instead, consider use +ve to convey other useful information,​ e.g. the number ​of successfully processed data units. 
 +      * Rajesh is concerned if it makes sense to define ​common ​errcodesif one is expecting each module/​accelerator to define its local errcodes. Lingli suggested common errcodes can be helpful either way we take.  
 +    * for call back functions, the suggestion is to define callback function types and then further define its arguments. 
 +    * for type term, use the Linux standard. 
 + 
 +Rajesh suggested in also collaborate with other teams working on virtio-cryto at OASISLingli would try to involve them into further discussion. 
 + 
 +Examples are to be added for la-ipsec and la-pdcp usecases. 
 +   
 ===== Follow-up action ===== ===== Follow-up action =====
  
-  - post the initial ​draft of guidelines to list review.+  - post the initial ​proposal ​of guidelines to online doc 
 +  - address the comments 
 +  - add examples 
 + 
 +====== NOMAD Southbound API ====== 
 + 
 +{{:​dpacc:​nomad_sb_api_discussion-20160225.pptx|discussion slides}} 
 + 
 +Skipped due to time limit, postponed to next week's call.
dpacc/minutes20160226.1456475695.txt.gz · Last modified: 2016/02/26 08:34 by Lingli Deng