Attendants: Lingli, Keith, Bob, Paul, Howard, Mario, Ola, Micheal, Rajesh

• gap analysis on openstack
• Lingli goes through the latest update on the doc summarized in update discussion
• Update Summary
  • Minor editing on Section 1-3
  • Merge Section 4 "Requirements" with Section 5 "Gap Analysis". Requirements are grouped with the specific lifecycle management. And gaps are intended to be added accordingly
    • Add EPA introduction to the new Section 4 "Gap Analysis"
    • The Current layout of the Section for "Gap Analysis"
      • 4.1 Openstack Background: Basic Functions, EPA Introduction, Proposal: Dedicated Acc Management
      • 4.2 Accelerator Life Management: Resource Discovery, Resource Selection, Resource Allocation, Resource Update, Release
      • 4.3 Summary: Requirements, Gaps
• Comments & Feedbackslides(with comments)
  • On Page 7 for "Nova Extension vs NOMAD"
    • The current table groups CPU instruction set extensions into the category that should be exposed the NOVA way.
      • Some of them, for instance Intel AES-NI and AVX2, can also be exposed as software implementation for abstract accelerator and be managed by NOMAD. (Keith)
      • Need another review and grouping accordingly. (Lingli)
      • Add a column for abastracted accelerator types to be supported by NOMAD. (Micheal)
    • In the table, "VMs direct access to accelerators" is stated as one of the pros for NOMAD way
      • Need clarification on this “VM direct access to accelerator. Does it not supporting Virtio interface access of accelerator from VM? (Bob)
      • Virtio is meant for data path access. (Howard)
    • For the Cons of NOMAD way, there is potential scalability issues for NOMAD, as the number of compute nodes under its management increases. (Paul)
      • Agreed. (Howard)
      • Will bring workflow design to discussion later which needs to take this into consideration. (Lingli)
  • On Page 8 for "Requirements for Resource Discovery"
    • A new requirement is proposed
      • Requirement VIM (or AC?) SHOULD maintain the mapping (change to mapping dependency?) between abstract acceleration resource to physical acceleration resource.
      • Remaining issues to be addressed/confirmed
        • Who should maintain the mapping, VIM or AC? Howard prefers VIM.
        • Should we change "mapping" into "mapping dependency"? Micheal suggests the latter.
        • Lingli suggests to post these questions to the online doc for feedback.
    • Keith feels the need to include also notification scheme when an accelerator break down. Lingli explains that there are corresponding requirements on "fault management" for "resource release" in following sections.
  • On Page 9 for "Acceleration resources features", which is aligned with ETSI NFV IFA004
    • Bob will bring more feedback after team review later.
    • Micheal is confused about the relationship between IFA004 and this document. Howard clarifies that IFA004 is high level considerations, while this doc is more focused on implementation gaps.
  • On Page 10 for "Gaps for Resource Discovery"
    • For the current example for Metadata definition, Keith feels it is too low level detail to be included in the current doc. Lingli agrees.
    • For the current API definition example, Bob will bring more feedback after team review later.
  • Page 10-15 are left for further discussion due to time limit

1. Update the doc according to the comments during the call (Lingli)
2. Refine the table for "EPA v.s NOMAD" and post it to the online doc, for further feedback (Michele)
3. Refine work plans in Section 5, and bring Nomad Architecture and workflows to the next discussion (Lingli&Howard)

• DPACC Usecases
• Lingli goes through the table of contents and calls for further review and feedback online
• Rajesh adds a subsection for "DPDP offload acceleration usecase"
• Lingli adds a subsection for "vRAN" as another "targeting applications"

1. Summarize the current documents and call for review in the list (Lingli)

• DPACC calls are canceled for next week, for the approaching Chinese New Year.
• Lingli will continue work on Requirements and Gaps for the other four management phases (Resource Selection, Allocation, Update and Release) bring them to our further discussion.
• Rajesh will continue work on common g-API for virtio-XXX acceleration usecases and bring it to our next discussion.