Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • January 15, 2016
    • Minutes
      • gap analysis on openstack
        • baseline doc: gap_analysis_on_openstack_for_dpacc.docx
        • work-in-progress: https://docs.google.com/document/d/1_fOinIQNcPwNODZPzGK5vRMPJQLwL7iLds4NFnjXSms/edit?usp=sharing
        • Lingli/Howard/Yuanpeng went over the current work-in-progress doc
        • Lingli: Figure 3-2 is currently borrowed and needs to be aligned with DPACC architecture.
        • Paul: Figure 3-2 is not reflecting the fact that acceleration management agent collaborates with various VIM agents in VNF lifecycle management events.
        • Lingli: Since Section 4 requirements is based on ETSI IFA 004, suggest to use a simple reference to keep updated to its latest version. Or for practical reasons, to refer to a snapshot or part of its content based on the actual work plan.
        • Yuanpeng: More detailed gap analysis for openstack and design for nomad is coming soon.
      • follow-up discussion on virtio-pdcp
        • Rajesh went over the responses to earlier discussion: virtio-pdcp-dpacc-questions.xlsx and calls for more feedback. The team is working on a new revision for further discussion next week, which is more aligned with another proposal for virtio-ipsec-la.
        • Lingli: Both g-api proposal and virtio-xxx extensions are mixed in the current doc, but actually are at different levels of DPACC arch. Suggest the authors to split the proposal into several docs, g-api is within DPACC scope but virtio-xxx are also relevant to OASIS.
        • Lingli: Concerned with ad hoc efforts in proposals of virtio-xxx for different DPACC use-cases without proper documentation for the use-cases and requirements. Suggest to prioritize what is important for dpacc and how to collaborate with OASIS.
          • Micheal: It is better to document the use-case and requirements before implementation and standardization.
          • Ola: The progress of virtio@OASIS is very slow. The usecases discussed here may not be of interest to that group.
          • Lingli: If the usecase is recognized and requirements identified and accepted, then DPACC could take over for implementation/integration if necessary.

            code

             

            {group3}
  • December 18, 2015
    • Minutes
      • America (3:00 UTC)
        • Attendants: Keith, Bob, Lingli, Gongxiao, Mario, Howard
        • Keith/Bob: high level requirements
        • Goes over the updated sections 5, 6, 8, 9 and 10.
        • Sections 7 and 11 are left for group discussion next Monday.
      • Europe: (9:30 UTC)
        • Rajesh: virtual accelerator for PDCP accleration
        • Attendants: Raj, Ola, Lingli, Paul, Francois, Mario
        • Raj goes over the remaining part of virtio-pdcp proposal from Freescale (Section 7 and onward), live tech discussion over the design.
          • Earlier proposal to use separate vqueues for command and packets, the implementation uses only one queue for both cases. It is agreed that the interface should provide both asychrononous and synchronous mechanisms for the upper application to choose. But not a mixture for different traffic types (e.g. commands and packets) on a single queue.
          • Ola pointed out that the union/enum types used in the headers can be problematic against the target for a well-defined binary interface. Raj turns to agree and will come back with more clarifications later.
        • Follow-up discussion for virtio-XXX proposals
          • Lingli: need input to the current chartered items (e.g. gap doc) for virtio-XXX on each of the usecases
          • Ola: Freescale should be more actively involved in pushing virtio-XXX to be standardized in OASIS
          • Lingli: Need offline discussion over the collaboration between DPACC and various virtio-XXX threads for acceleration in OASIS

...

...

  • July 15, 2015
  • Agenda
  • All: B-release work plan discussion
    • All: Planning discussion for OPNFV Hackfest
    • Keith/Bob: status summary of high-level requirements for dpacc
    • FF/Wei (tentative): acceleration related MANO descriptors
    • Srini/Subha (tentative): g-api for virtio IPsec
      • api_guidelines_00.pdf
      • freescale-ipsec-virtual-accelerator-gapi-rev01.pdf
      • Minutes
      • Bob Monkman hosted the meeting and created these minutes. Please help to correct any omissions/errors
      • FF/Wei did not make the meeting and so we decided to use more time to cover discussion on planning for B-Release and OPNFV HackFest- 30 Minutes
      • B-Release outline had been sent by LingLi -China Mobile, to guide the discussion
      • initial plan: started as a requirement project
        • two-phase work plan
          1. 2015: documentation & demo ('demo' was advised to be changed to PoC or Prototype during the call)
            1. 2016: code integration
            2. Discussion: We noted that we had not until now discussed 2016 and had originally planned 1H'15 to be requirements phase and 2H '15 to be Collaborative Development Phase. We were not sure what was precisely meant by Code Integration, but Bob M speculated, and seemed to get agreement that:
            3. (a) 'demo' may have referred to the results of PoC(s) proposal(s) for g-API, binary compatibility (virtio) etc to meet requirements, and...
            4. (b) we think now that even as we wrap up requirements and transition to PoC work and assessment, these will likely take longer than anticipated code freeze date of late Nov/early December 2015 for Brahmaputra. More likely that this will spill into 1H 2016 somewhere and we are not likely to intersect with Brahmaputra.
Code Block
      LingLi question: shall we stick to the initial plan or plan for code integration?
     Discussion: we did not have sufficient understanding of this to comment

{group3}

Code Block
      We would need to have LingLi clarify and we may continue the discussion next week or at the Hackfest.
     

{group3} * OPNFV HackFest

  • Bob went over the background of why the topics were chosen for the 3 topics areas were chosen.
  • No objections to the broad categories, but questions did arise about when Friday session would close (it definitely shows content into Friday after lunch but no clear end time.
    • Questions raised about needing more Applications oriented folks and VMWare rep indicated he would check with Brocade (Vyatta), Bob will check with F5 who had made comments on priorities in the past. But noted that DPACC is lacking in broad VNF/application stakeholder participation.
  • High Level Requirements- 20 minutes: Tried to address a number of new questions and comments on existing requirements from Linaro's Bill Fischofer. In doing so, we got a bit mired in the potential difficulties in realizing desired outcomes that would please all stakeholders.
  • Bob suggested that Bill, Bob, Rob Dimond (who had fixed up sections 6 & 7) and Keith work offline to try and clean up most of the edits , questions off line and so this is out action item. Bob will reach out to the parties to coordinate.
  • Freescale API proposals around virtio
  • Subha was on the call but with 9 minutes remaining we decided that it might be best to have the team review further the 3 documents and we could resume the discussion on them on a future call.
  • Here is the list of Freescale contributions on the ipsec_la:
Code Block
    1.	Virtio IPsec Messages: 
        https://wiki.opnfv.org/_media/dpacc/freescale-ipsec-virtual-accelerator-rev-3.docx
             
   2.	G-API guidelines: 
        https://wiki.opnfv.org/_media/dpacc/api_guidelines_00.pdf
        
   3.	G-APIs for Virtio IPsec

{group3} https://wiki.opnfv.org/_media/dpacc/freescale-ipsec-virtual-accelerator-gapi-rev01.pdf

...