dpacc:minutes20160226
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dpacc:minutes20160226 [2016/02/26 23:00] Lingli Deng [vRAN application update] |
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, Paul, Michele, Trinath, Jesper | + | Lingli, Keith, Yannan, Denis, Rajesh, Howard, Barat, Ola, Mario, Paul, Michele, Trinath, Jesper |
| ====== Arch doc update review ====== | ====== Arch doc update review ====== | ||
| Line 57: | 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 73: | 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 94: | Line 97: | ||
| * {{:dpacc:g-api_guidelines_discussion-20160225.pptx|discussion slides}} | * {{: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}} | ||
| 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. | 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. | ||
| - | Keith raised the question on the closed box approach would not work for open source, Lingli 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. | + | Keith raised the question on the closed box approach would not work for open source, Lingli 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) | 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 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 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, suggestion is 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 example, the 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. | + | * 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 example, the 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 errcodes, if 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 call back functions, the suggestion is to define callback function types and then further define its arguments. | ||
| - | * for type term, use the Linux stardard. | + | * for type term, use the Linux standard. |
| + | |||
| + | Rajesh suggested in also collaborate with other teams working on virtio-cryto at OASIS. Lingli would try to involve them into further discussion. | ||
| Examples are to be added for la-ipsec and la-pdcp usecases. | Examples are to be added for la-ipsec and la-pdcp usecases. | ||
dpacc/minutes20160226.1456527654.txt.gz · Last modified: 2016/02/26 23:00 by Lingli Deng
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
