Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.

====== Agenda ======
       *  Update on dpacc architecture {{:dpacc:dpacc-architecture-update_20160219.pptx|slides}}[[https://docs.google.com/document/d/1O4rtCh1vbTOO5cMwmRwfv3UJb_bVWZrqXQS_-QJAk10/edit#|draft]]
       * Update on dpacc usecases {{:dpacc:dpacc-usecases-update_discussion_20160219.pptx|slides}}     [[https://docs.google.com/document/d/1eu2489SYeVL180ZzjnagrXTUM1Qh37GKs6N6rRYDVNM/edit#|draft]]
       * Update on gap for openstack {{:dpacc:gap_analysis_on_openstack_for_dpacc-update_discussion_20160219-clean.pptx|slides}}     [[https://docs.google.com/document/d/1_fOinIQNcPwNODZPzGK5vRMPJQLwL7iLds4NFnjXSms/edit|draft]]
       * common g-api discussion for ipsec and pdcp {{:dpacc:opnfv-discuss-common-gapi-20160219.pptx|slides}}

====== Attendants ======
Lingli, Keith, Paul, Yannan, Arun, Gandhar, Rajesh, Trinath

====== Usecase doc update review ======

  * {{:dpacc:dpacc-usecases-update_discussion_20160219.pptx|discussion slides}} 
  * [[https://docs.google.com/document/d/1eu2489SYeVL180ZzjnagrXTUM1Qh37GKs6N6rRYDVNM/edit#|work-in-progress]]

===== figures update =====

  * Denis latest revision reviewed, need clarification from Denis for the kernel app/sal case. 
  * Keith refined the user space sal case later after the call. 
  * Denis acked Keith’s comment and Lingli merged two proposals for further review.

===== vRAN application update =====

Yannan refined the figure in moving the text out, and add description of the LTE stack to identify other accelerator usecase in addition to PDCP. 
  * Keith asked if crypto acceleration is applicable there. Lingli remarked that while PDCP acceleration contains partly crypto acceleration as well as specific protocol processing and does not use generic crypto acceleration, there is no other crypto processing in the stack.
  * Vineet: the leftmost box should be changed into GTP, which can also be accelerated via hardware offload. Yannan would help respond offline.

===== Follow-up actions =====


  - Figure update: update virtio-lookaside figure in Section 4 and continue working on individual usecase diagrams accordingly.
  - Application update: Yannan would respond to Vineet’s comment offline and update.

====== Arch doc update review ======

       * {{:dpacc:dpacc-architecture-update_20160219.pptx|discussion slides}}
       * [[https://docs.google.com/document/d/1O4rtCh1vbTOO5cMwmRwfv3UJb_bVWZrqXQS_-QJAk10/edit#|work-in-progress]]

  -   removal of quest AML: agreed.
  -   use H-SAL and G-SAL instead of Host SAL and Guest SAL: preferred no change.
  -   refer to Nomad as AML implementation: No strong opinion. Prefer no (Lingli)

===== follow-up actions =====

Intend to finalize it internally and submit to review in larger group.
    * Contributors: Check the online comments and respond to them;
    * Commenters: confirm your comments are properly addressed;
    * Editor: close the confirmed issues.

====== Openstack Gap update review ======

       * {{:dpacc:gap_analysis_on_openstack_for_dpacc-update_discussion_20160219-clean.pptx|discussion slides}}
       * [[https://docs.google.com/document/d/1_fOinIQNcPwNODZPzGK5vRMPJQLwL7iLds4NFnjXSms/edit|work-in-progress]]

===== Refined comparison table review =====
(Page 4) Refined comparison table review: agreed.
===== Nomad Architecture review =====
(Page 5) Nomad Architecture review: Need further discussion on the specific functionality of the HACC-API which is supposed to be part of enriched s-API.
===== Requirements & Gaps =====
==== (Page 6) Requirements Groups review ====

    * Paul has concerns about mandating fine-grained QoS control for current VIM implementation. Lingli clarified that the requirements are for Nomad enhanced VIM.
    * Keith suggested to change “QoS control for powerful accelerators” into “QoS control”as this is intended to be generic requirement rather than specific to only powerful accelerators. Lingli agreed and updated the slides accordingly.
    * Keith is concerned about only stating “fault management”as MAY, and prefers it to be a MUST. Lingli clarified that accurate problem diagnosis is thought to be out of scope.

==== (Page 7) Requirements on Resource Discovery ====

    * same comment for QoS control and “powerful accelerator”.
==== (Page 8) Gaps for Resource Discovery ====

    * Agreed to remove the current meta example table, but mark a follow-up action to specify acc functionality and KPI abstraction in a separate WI.

==== (Page 9-) ====
 
Time runs out and left for offline review and feedback.

===== follow-up actions =====

  - Call for review for the newly refined Section 4 and 5
  - Create a WI for IM and DM on both abstract and physical acc resource
  - Start work on the required functionality for s-API enrichment

====== common g-api discussion ======

       * {{:dpacc:opnfv-discuss-common-gapi-20160219.pptx|common gapi discussion}}

===== 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” APIs, which 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 usecases, as they differ fundamentally in the control/data format to be conveyed. 
  * Lingli clarified the vision was actually a guidelines for virtio-xxx spec/proposal, which 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 proposal. https://wiki.opnfv.org/_media/dpacc/api_guidelines_01.pdf 
===== Follow-up action =====

  - post the initial draft of guidelines to list review.
Wiki

User Tools

Site Tools

Page Tools
