Wiki

User Tools

Site Tools

Trace: • meetings
dpacc:meetings

Table of Contents

List of Drafts

Work items

Weekly project meetings

Agenda for the next meeting

  • Agenda
    • TBA

Meeting logistics

Past meetings

  • March 11, 2016
    • Agenda
      • Update Summary for api guidelines
      • Attendants: Lingli, Howard, Keith, Arei, Denis, Rajesh, Paul, Varun, Arun, Mike, Michele
      • Minutes20160311
      • Follow-up actions
        • API Guidelines:
          • Revise the current doc to address current comments.
          • Need Global Registry for acc ID to be referenced in errcodes
        • Meta Data:
          • Contact author of IFA004 for further clarifications on Number of Contexts/Data Format.
          • Need further input on various element/format specifications for non-PCI accelerators.
        • Initiate C-release planning discussion
  • Febrary 19, 2016
    • Agenda
    • Attendants: Lingli, Keith, Paul, Yannan, Arun, Gandhar, Rajesh, Trinath
    • Minutes20160219
    • Follow-up actions
      • current work-in-progress: arch/req/usecase/gap-openstack
      • new discussion threads: acc type/metric spec, s-api enrichment for mgmt, common api guidelines
  • Febrary 5, 2016
    • Attendants: Lingli, Keith, Bob, Howard, Paul, Micheal, Michele, Mario, Rajesh, Ola
    • Minutes20160205
    • gap analysis on openstack
      • Lingli goes through the latest update on the doc summarized in update discussion
        • 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"
      • Comments & Feedbackslides(with comments)
      • Page 10-15 are left for further discussion due to time limit
      • Follow-up actions
        • Update the doc according to the comments during the call (Lingli)
        • Refine the table for "EPA v.s NOMAD" and post it to the online doc, for further feedback (Michele)
        • 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"
      • Follow-up Actions
        • Summarize the current documents and call for review in the list (Lingli)
    • About Next Discussion
      • 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.
  • January 29, 2016
    • Minutes20160129
      • Friday 3:00-4:00 UTC https://global.gotomeeting.com/join/230251565
        • Attendants: Lingil, Bob and Howard
        • dpacc architecture
        • review the comments made by Ola
          • It is clarified that hio enabling pass-through access to hardware is not capable to provide binary portability for VNFs. Since binary portability is specified as a should-have requirement for dpacc, it is acceptable to include hio with pass-through access to provide an option to a VNF for better performance. A note is added to Section 2.1.1.4.
          • Question raise to the SRL role in packet forwarding/switching path in Section 2.1.2.3. Suggestions are made to add packet flow chart/arrows to clarify the paths of different cases (e.g. where SRL does packet forwarding or switching and as depicted in Figure 4) to see if there is any remaining issues.
          • Question regarding confining hio@host to be accessed only by host SAL. The context is confined to host interface, there is another description for hio@guest in Section 2.1.1.4.
        • Brief introduction of host AML in Section 2.1.2.5 and gap-openstack
          • Section 3 the architecture is described, where a dedicated management function is added for accelerator resource orchestration.
          • Section 5 gives a introduction of Openstack implementation, EPA features and clarifies the considerations for adding a standalone management controller instead of relying solely on Nova extensions.
        • A new openstack project Nomad is initiated to implement this idea and several organizations shows interest.
  • January 22, 2016
    • Minutes20160122
      • Friday 3:00-4:00 UTC https://global.gotomeeting.com/join/230251565
        • host AML discussion
        • In previous figure EPD is not existent in DPACC arch, it is referring to as sio? YES.
        • AML is using s-API and making use of g-drivers within AC instead of acc drivers in host kenerl for device access. And current DPACC Arch does not include any components from host kernel.
        • Add another arrow between Compute Management Function and other functions (for network and storage managements) and Acceleration Management Function, for VNF deployment events as described later in Section 5.
        • Although there are such interactions in the previous figure between guest and host, it is not suggested to extend sio-backend to expose the host AML to guest, so that VNF is agnostic to VIM orchestration and management. It shall be noted that there are clear difference between orchestration and configuration, the former is done by AML as part of VIM, and the latter is done by VNF as part of data path setting up/association.
        • Updated Discussion slides
        • Updated host AML description@dpacc-arch
        • Updated host AML description@gap-openstack
      • Friday 9:30-10:30 UTC https://global.gotomeeting.com/join/623117821
        • follow-up discussion on virtio-pdcp
          • renewed doc for g-api
          • Rajesh goes over the g-api proposal for virtual dpcp lookaside accelerator
          • Lingli: reagarding management API, is it interacting with the orechestration of VIM. For instance, after close or before open, can the underlying accelerator be assigned to another VNF, or even getting preexempted after open or before close.
            • Rajesh: No. The VNF assumes the virtual accelerator be always available. But it needs to first get a handle for using it. That's what open and close for.
          • Lingli: for control and setup API. Are these aligned with virtio-ipsec-la?
            • Rajesh: The management APIs are common. But not the control and setup APIs. Although they look alike, but some of the specific arguments are different. One reason is ipsec case uses kernel protocol implementation but dpcp does not. And ipsec shares same instance with multiple application, but PDCP is not.
            • Rajesh: Let us have further discussion offline to see if we can merge APIs for kernel and userland implementations.
            • Lingli: let me mark an AR to connect to Denis for this too.
          • Rajesh: We are using different set of errcode definitions from ipsec. Do you suggest to have -ve value for failure error code?
            • Lingli: Yes. If there is no technical issue, common design is good and easy to follow.
          • follow-up actions
            • Lingli will work with Duanran to produce additional input for usecase documentation for pdcp accleration on vRAN scenario.
            • Rajesh will do minor update to the g-api for pdcp, and forward it for group review.
            • Start discussion among different groups and document common design considerations for virtio-xxx proposals for DPACC usecases.
  • 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.
  • 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
  • December 11, 2015
    • Minutes
      • America (3:00 UTC)
        • Keith/Bob: g-api requirements
        • Attandents: Keith, Bob, Paul, Lingli
        • Expressed the need to clear up the content by the end of this year. Agreed to set up an offline thread for close collaboration between major editors and contributors in America to boost progress and report update online during project calls.
        • Goes through g-api requirements section briefly.
        • new baseline revised later by Mike
        • A new Google doc created by Bill for group review and further collaboration.
      • Europe: (9:30 UTC)
        • Vineet/Rajesh: virtual accelerator for PDCP accleration
        • Attandents: Vineet, Rajesh, Duanran, Lingli, Paul, Mario
        • Vineet presents an introduction to the usecase of vRAN acceleration for pdcp protocol, including both encryption/decryption acceleration and header compression acceleration.
          • Ola: why not reuse virtio-ipsec or virtio-crypto for enc/dec acceleration? do we need to define another virtio-interface for each of every use-case?
          • Lingli: is it possible for a physical accelerator to expose both virtio-ipsec/virtio-crypto and virtio-pcdp simultaneously to the local manager or VIM for orchestration and resource sharing between different VNFs?
        • Vineet goes on in presenting the general architecture (which currently indicates that the accelerator is abstracted as the PCIe device in the host) in the diagram.
          • Duanran: PCIe interface is prone to high delay and jitter that are undesirable for vRAN usecase.
          • Vineet: Currently, the accelerator is attached to the compute as a PCIe device, but the general architecture can be extended to support non-PCI accelerators. Need to refine the diagram to reflect this point.
        • Vineet goes through Section 6.1 for “virtio-pdcp device definition”, including the device registry and feature bits definition. There is also a dedicated subsection, describing the multi-queue policy configuration for the virtual device interface.
          • Lingli: Multi-queue support and configuration is a feature that might be shared with different acceleration usecase, suggest a sync with other virtio-device interface proposals, e.g. virtio-ipsec-la and virtio-crypto.
        • Summary and follow-ups
          • Lingli: vRAN is an interesting usecase, support to continue work on working on the use-case. However, performance metrics (e.g. delay and jitter) rather than throughput are dominating factors that need to be considered and demoed to relieve the concern that virtio-based solution can be viable.
          • Vineet: Need further clarification on the questions via email due to bad audiao quality during the call.
  • December 4, 2015
    • Minutes
      • America (3:00 UTC)
        • dpacc management DPACC Management Aspects
        • Howard is proposing to work on adding a separate top-level module "Rock" to openstack for unified accelerator management, and I will let Howard and Peng to elaborate more on the plan.
        • There is also a work-in-progress draft on the north-bound interface between VNFM and VIM for acceleration management, IFV004@ETSI NFV ISG, which is not publicly available now for list discussion of non-ETSI members, but could be shared offline for discussion
        • Another concern is how this proposal would benefit from and collaborate with EPA to Nova, which is already partly available from Kilo release.
  • Europe: (9:30 UTC)
    • Virtio work update and discussion
      • virtio-crypto
      • virtio-crypto PoC
      • Background Introduction
        • Gonglei: This is a PoC done this year and is currently submitting for standardization at OASIS, and planning to upstream the code. An early draft of OASIS spec will be shared with the dpacc team offline. Expected to output an revision next week.
        • General Architecture
          • Ola: Regarding the scope of the proposed virtio-crypto interface, will it including other relevant accelerator capabilities, such as random number generation?
        • Performance Optimization
          • Gonglei: the current performance bottleneck is at the global lock of the QEMU main process, and multi-queue solution would not help.
          • Varun: Have you consider using user-space BE driver implementation to enhance the performance? we have some experience.
          • Gonglei: Sounds promising, interested in further discussion.
          • Varun: Also by using inline acceleration, IPsec performance would be enhanced.

Dpacc Breakout

  • November 4, 2015
    • Minutes
      • (10min) Planning for dpacc breakout session@design summit
        • Suggested time and location: 15:30-18:00 Tuesday, Breakout Room#1
        • proposed agenda
          • Lingli(10min): Project overview and work item status
          • Keith/Magnus(20min): dpdk for dpacc and PoC on ARM SoC
          • Srini/Rajesh(20min): gap analysis and requirements of flow-api for inline acceleration
          • Denis(20min): virtio-ipsec PoC for offload acceleration
          • All(30min): priority discussion and next step proposals
          • Openmic(20min): mgmt aspects etc.
          • Tentative: dpacc high level requirements
      • (40min) dpacc high level requirements (open source and g-api requirements)
  • October 21, 2015
    • Agenda
    • Minutes
      • Bose presented the slides to the team. There are two use-cases for IPSec acceleration (one for tunneling between vRAN and vEPC, another one for tunneling between smallcells and GW). The testing setup is based on a simple IP traffic generator, two DUTs doing tunneling between one another.
      • Discussion
        • Agreed to be served as initial input to test-spec.
        • Lingli: Currently organized as an application level performance testing, which is common for all acceleration methods (LA or inline) and implementation for IPSec (directIO or virtio).
        • Keith: Suggestion to eliminate the impact from fragmentation caused by large packets to the IPSec performance testing
        • Varun: Need further consideration on the configuration of the cores dedicated to the host is dedicated to the virtio-backend for virtio-based implementation.
        • Ola: Different methods for IPsec acceleration might need different testing setup. No answer yet, will provide input later.
        • Keith: Need functional testing for extended interfaces like virtio-ipsec. Will provide input later.
  • October 14, 2015
    • Agenda
    • Minutes
      • serving for clarifications on openflow method for dapcc usecase and gap analysis on openflow
      • Lingli asked for comment on including the case into B-release documentation and no objections was heard.
      • Questions raised during the following discussion
        • Consider use P4 for programming interface.
        • Need further clarification for the g-API requirements for flow programming.
        • Need further clarification on whether directIO be used for sio besides virtio in this case.
  • September 23, 2015
    • Agenda
    • Minutes
      • Lingli goes over the changes and suggestions for documentation https://etherpad.opnfv.org/p/dpacc-tasks
      • Gap analysis: https://etherpad.opnfv.org/p/dpacc_gap
        • Currently, dpdk, odp, virtio, openstack and openflow are listed to be analyzed further for dpacc requirements
          • dpdk/odp: Keith, Bob committed to contribution to gap-dpdk and gap-odp, respectively
          • virtio: Magnus would cooperate with Subha and Ola for gap-virtio, where Subha had submitted new content for virtio-ipsec-la usecase
          • openflow: marked as TBD after further discussion
            • Subha recalled Freescale had provided an implementation for virtio over openflow. Srini helped in clarifying that Idea is to define flow g-API from vNF. These flow G-API internally convert it to OF messages and program the OF backend. Skip suggested that whether openflow or P4 might be the G-API could be an interesting discussion topic. Subha and Srini took the action to come back with further clarifications.
      • Test spec: https://etherpad.opnfv.org/p/dpacc_test
        • Srini and Bose committed to working on test spec for IPsec acceleration, mostly performance tests for specific VNF usecases.
        • Keith and Magnus suggested to include functional tests for enhanced interfaces, like virtio
        • Srini indicated and people agreed that the work-in-progress IPSec-LA PoC is using virtio, it should cover virtio functional test, and if there are some virtio functions that are not exercised by IPSec-LA use case, then we need to identify them and define test cases.
      • Usecases: https://etherpad.opnfv.org/p/dpacc_usecases
        • Lingli changed the proposed structure of the doc and called for review and comments
        • Bob would come back with further feedback after internal discussion
        • BobD requested for clarifications on the acceleration models and listed usecases
          • Lingli clarified that the "acceleration models" section covers the general definitions of different models, including the look-aside model. And the target is an VNF application scenario, i.e. an IPsec GW, and there are different ways to accelerate its data plane, which are listed as 4 usecases.
          • Srini further clarified that Use case 1 - Using look-aside crypto accelerator, Use case 2 - Using instruction level crypto accelerator such as AES-NI, USe case 3 - IPSec protocol level acceleration, but still look-aside.
      • Framework: https://etherpad.opnfv.org/p/dpacc_framework
        • Left for list review and next meeting as no time left for further discussion.
    • chatting_log_0923
  • September 16, 2015
    • Agenda
    • Minutes
      • Switched to IRC chatting for GTM issue
      • Went over the slides for B-release planning discussion1_b-release_planning_for_dpacc_documentation.ppt
      • On work items and their dependencies (Pages 2-3)
        • Keith suggested remove the dependency to QTip if we only use their testing framework. Lingli took the AR to ask for clarification from the list further and create Jira tasks by Friday.
        • Magnus volunteered to be the editor of gap analysis for virtio.
        • Keith and Bob took the AR to contribute gap analysis for DPDK and ODP, respectively.
      • On proposed next steps (Page 5)
        • The Authors took the AR to try to provide a clean version of "high level requirements" after Friday's offline discussion for list review by next Monday
    • chatting_log_0916
  • September 9, 2015
    • Agenda
    • Minutes
      • B-release planning update
        • Lingli proposed to join B-release project for dpacc documentation. No objection. The team will work on deliverable planning and dependency identification next week.
          • There was a brief status review over current work-in-progress deliverables:
            • Framework: a lot of contribution here, needs coordination and organization
            • Requirements: Keith will coordinate offline with Bob and Bill and bring a new version for team review by Friday
            • Usecases: Subha will provide text for IPSec accleration.
            • Test specs: Srini and Bose will coordinate with QTip team and contribute on IPsec benchmarking.
            • Gap analysis: Keith has done the gap analysis for dpdk regarding gAPI requirements. It is expected that one would do the same for ODP. And Bill, Ola and Bob would coordinate offline and come back with this comment.
      • Dpacc session for OPNFV summit planning update: Since no dedicated dpacc mini summit session is granted for OPNFV summit, need more coordination for dpacc demos during the prior hackfest session. Further discussion might be needed after Lingli collected all the potential demo requests/updates.
        • New demo proposals should be sent to Lingli by this week.
        • Updates are expected from Freescale and Linaro team
      • Dpacc requirements review https://etherpad.opnfv.org/p/dpacc_high_level_requirements
        • Keith pointed that the DPDK team is working with Bob and Bill, as well as Cisco and ATT people on convergence of DPDK API and ODP feature, e.g. crypto API. * The proposed crypto module would be integrated with DPDK 2.2.
        • The team go through Lingli's comments except the gAPI section. Keith would work offline with Bob/Bill to address remaining issues and provide a clean version for team review by Friday.
    • Recording http://v.youku.com/v_show/id_XMTMzMTcwMjgxNg==.html?f=26010297
  • Auguest 26, 2015
    • Agenda
    • Minutes
      • Freescale will be providing a complete demo including the VNF (VPN concentrator or IPSec GW), virtio-frontend for IPsec in the guest, virtio-backend in the host for Freescale hardware accelerator and QEMU enhancements by September. Others are also joining. The joint demo is tentatively targetted at OPNFV Summit in November.
      • Relevant documents can be found at github and wiki page
      • The current work-in-progress PoC is using a tight and vendor specific implementation for virtio-IPSec backend. Should it be another layer of abstraction for the backend (e.g. via SAL in the host) is left for further discussion.
      • Planned testcase is to compare the performance with or without hardware acceleration. Bob suggested to include the evaluation of the overhead for virtio in comparison to direct IO. Srini indicated that it is possible to have direct connectivity of accelerators to VMs, but it is not in the scope of POC project. Hence PoC team consider performance comparison with direct IO at later time.
      • Questions on g-api requirement fulfillment (e.g. performance determinism, left for email discussion) and potential merge of proposed guidelines to g-api requirements.
      • Questions on management APIs and its relation to orchestration (left for further discussion, suggested reference include ODP's ODL integration design and ETSI NFV IFA 011)
      • Brief discussion on possibility of common testing setup for different PoCs. Potential collaborations with other projects, e.g. Funtest (for traffic profiles) and QTip(for benchmarks), are advocated. Left for further discussion on the list.
    • Recording http://v.youku.com/v_show/id_XMTMyMDA5OTA4NA==.html
  • August 12, 2015
    • Agenda
    • Minutes
      • discussing, commenting and dealing with questions on Keith’s DPDK slide deck
        • Most of the time was spent looking at Slide 6 diagram https://wiki.opnfv.org/_media/dpacc/opnfv-dapcc-hackfest-20150730.pptx
        • Question was asked about how DPDK could support other acceleration hardware.
          • Keith indicated the DPDK community is adding more acceleration support for other hardware types and new APIs must be created to support these new devices.
        • Keith discussed that they were working on new Crypto, DPI and other APIs. The question was raised about how dependent DPI would be on HyperScan Intel technology.
          • Keith replied that the APIs should be able to support other methods. DPI was used as an example here and the current possible solution was Hyperscan. The point is we need to support hardware and software solutions plus the DPI API must not be vendor specific in any way. The PMD layer is were the vendor specific abstraction to the hardware is placed in DPDK.
          • DPDK can support any number of devices hardware or software at the 'same time', plus support SoC devices too. DPDK has a two layer device model which the PMD being the interface to the hardware or software SoC SDK. The top level is the API to the applications and it must be generic to support all device types hardware or software solutions.
        • Keith stated DPDK appeared to be the only solution that provides hardware and software solution we can point to now.
          • It appeared currently ODP did not support more than one SoC or device (independent of the SoC) at the same time, but the ODP team stated they do support other devices.
          • But these designs appear to be proprietary to the vendor's and not open.
          • Might need more clarification from the ODP presentation next time.
        • The question was asked as to what open forum with what membership worked on these new APIs. Keith replied that these were discussed some time back on DPDK.org. Not clear how the APIs were then agreed however. Needs more discussion.
          • Keith replied that these were discussed some time back on DPDK.org. The APIs are normally submitted to DPDK.org as RFCs or patches then the community discusses the APIs plus they suggestion changes and options. It is a community and open source project, which means the community must agree by ACK/NAK of the suggested solution. Only when the issues have been resolved are the changes accepted.
        • Bob asked why the DPDK team did not reach out to ODP team for its Crypto APIs.
          • Keith replied that this was because the team could see the code in ODP and the API is very similar to just about all other APIs for Crypto today, which had not been accepted in its current form by the DPDK community.
          • Keith asked why these APIs were not submitted to DPDK
            • Bob later came back to this to note that 6Wind told the ODP project that someone would have to pay in order for any patches to be accepted from ODP project.
            • FF further clarified via email that actually the joining the DPDK community is free and no money is required by 6Wind or any one else.
        • Ola asked how one would add support for statistics, lookups etc?
          • Keith stated that it was not true that all of the statistics in DPDK were maintained in software. DPDK does support a number of statistics today and most all of them are in hardware, which DPDK APIs read the hardware registers to obtain those values. For other hardware devices (like SoCs) which is currently not supported by the current DPDK API, this would require new APIs in DPDK.
        • Keith noted that the current DPDK release does not have a event based programming model, and wanted to add a event based programming model to DPDK.org as a supported solution.
          • There had been practice in putting OpenEvent Machine on DPDK in the past and some customers are using a event based programming model with DPDK.
          • It was suggested that ODP's event model, which is based on OpenEvent Machine, could be ported to DPDK for a solution.
        • It was noted that DPDK does not have a standard way to find a non-PCI device, but this is being added.
          • Keith further added via email that adding support for non-PCI devices, as been done by Wind River's VxWorks, could be a simple solution.
        • It was agreed that DPDK does not support an external memory manager and one needs to be added. This is something Keith is discussing with Linaro.
        • Bob noted there seemed to no direct hardware APIs- all through PMD but not sure if this is the case completely or if it will change in future.
          • Keith further clarified via email that the two layer device model of DPDK, which does not require direct APIs to hardware, allows DPDK to access any hardware through the lower device model while giving the application a clean API to access anyones hardware or software solution.
        • It was noted that Keith believed the driver level is the place where hardware abstraction should be done, not the application layer. While The ODP team has explicitly set out to support HW abstraction at the application level in its APIs.
          • Keith further clarified via email that he thought the correct hardware abstraction layer was at the PMD layer in DPDK, as it gives a much cleaner solution to support any number of devices at the same time while giving the user a clean API solution. Similar pattern of device layering can be found in any complex systems like Windows, VxWorks, Linux, FreeBSD, Android, iOS, MacOS, lwIP.
        • Question was raised about how a hardware scheduler would work in this DPDK model.
          • Keith replied that adding support for hardware scheduler, e.g. open event machine or similar, would have to be added.
        • Steve Furr and Bill F both noted that the separation of the API layer from the underlying implementation was critical with different HW configurations and programming models.
          • Keith agreed on this point. An application layer needs to define a set of APIs to provide a clean solution and can not be hardware specific as with the two layer device model in DPDK. He pointed out that it was not the case that DPDK was only concerned with software solution.
        • Bob discussed the challenges the ODP camp see in working in the DPDK.org structure given the unclear governance and lack of considered debate that all ODP features generally go through with both competitors and partners alike. This has resulted in a consensus compromise leading to ODP APIs we have today.
          • Keith responded that DPDK is a open source community and the governance is defined by the community not a single or small group of companies. As in any community the more active you are in helping define the product the more the product reflects your needs.
      • Due to the limit of time, it was suggested that the ODP presentation be covered next time, plus more on the Virtio discussion if possible.
        • Bob indicated that the ODP team would consider all the of discussions as they go through prototype generation which is already underway.
        • Bob noted that there would not be time for going over the ODP proposal but would like to do that at the next meeting (need 30-40 minutes), along with Virtio proposals if time allows.
        • Keith indicated that after some discussion at the Hackfest, he believes the virtio discussion and proposals are converging well.
  • July 30, 2015 (OPNFV Hackfest, July 30)
  • Agenda
    • DPACC -API Requirements Wrap Up & Proposals (3 hours, afternoon sessions on July 30)
    • g-api proposals (120min)
    • (30-60min) Discussion over standing concerns/Next steps on g-API
    • (Keith/Bob/Bill/others: 60min) High Level requirement wrap up
  • Minutes (for more detailed recording, please refer toMinutes for Thursday g-API session)
    • Bill's ODP overview and how it relates to g-API from ODP team perspective
      • Bill stated ODP was created from the start to have the same goal as g-API, application portability with leverage of differentiated accelerators for different vendors.
      • Bill pointed out ODP is an agreed API that representative from from OEMs (Cisco, Nokia, ZTE, Huawei), SoC vendors (Applied Micro, AMD, Broadcom, Cavium, EZChip, Freescale, Kalray) and ISVs ( MontaVista, Enea) work together to arrive. Even Intel has been represented.
      • Question on whether ODP-DPDK could be leveraged for its virtio support to enable the proposed virtio option for binary compatibility across a given Instruction Set Architecture.
        • Bill answered that, in theory, it could be, although this is not tested- compiled or ported to different CPU archs.
      • There was a discussion raised by Keith on the fact that ODP layer is open source, but few SoC implementations are published on the opendataplane.org site.
        • A: It was not necessarily mandatory that implementations not be published. Matter of choice.
      • It was presented that ODP team had in very simple cases reduced ODP-DPDK overhead to “negligible levels”, as is already the case for several SoC implementations. Also, there is a stated goal to ensure this is less than 2% for most cases and PoCs were in development to examine ODP performance with real world use cases.
        • Keith is concerned that this proposal would suffer a performance hit and break compatiblity for current DPDK customers. His counter proposal was having ODP/SoC SDK at the driver layer only. He argued that if the ODP layer is truly not effecting performance then running ODP as a PMD would not effect the SoC performance as well.
      • Keith’s updated DPDK perspective g-API presentation
        • Keith emphasized the desire to preserve DPDK investment by those who had created integrations with DPDK.
        • Keith argued that extending DPDK with ODP features is the right choice. The phase one design would be to have ODP as a set of PMDs to allow Intel, MIPS, PowerPC and ARM systems to use any configuration they so desire to meet their system goals.
        • There was new concrete proposal for folding certain ODP support into DPDK.
          • Configuration:
            • DPDK supports only PCI configuration model
            • ODP supports only SoC configuration model
            • Proposal: Combine the two configuration models
          • Memory manager
            • ODP supports a external memory manager for SoC controlled memory
            • DPDK support a high performance memory manager for devices without memory managers
            • Proposal: Combine the two memory manager models
          • Run-to-Completion and Event based model
            • DPDK uses Run-to-Completion for high performance
            • ODP uses Event-based model for programming model
            • Proposal: Combine the two run models
        • There was concern for the the proposed SoC model in DPDK, using ODP as a PMD, as the ODP team is convinced this would add unnecessary overhead and not applicable to all cases.
          • Keith responded that it seems his proposal would apply to a number of cases. And DPDK is already able to run multiple devices at the same time, plus SoC device if needed.
        • DPDK and ODP teams can assess the viability of supporting both memory manager models in their respective projects.
        • Bob clarified that ODP supported a simple polled mode operation as well as the event-based model.
      • Summary and next step discussion
        • It was agreed that the only way forward was to produce prototypes examining these sorts of options. It was also suggested that the DPDK and ODP teams really need to directly discuss and explore convergence in general.
        • ODP is adding better DPDK support in ODP and will likewise produce some prototype/POCs for assessment of the project.
        • Keith suggested the team focuses on adding the missing parts to DPDK to enable the ODP/SoC vendors, requesting help with a standard DPDK implementation for ARM.
  1. 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:
  2. (a) 'demo' may have referred to the results of PoC(s) proposal(s) for g-API, binary compatibility (virtio) etc to meet requirements, and…
  3. (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.
   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
   We would need to have LingLi clarify and we may continue the discussion next week or at the Hackfest.
   
   * 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:
 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
https://wiki.opnfv.org/_media/dpacc/freescale-ipsec-virtual-accelerator-gapi-rev01.pdf

please read the documents and we will take questions & comments on a future call.

Generally Bob asked that we work to resolve more questions on the list in between calls as it is difficult for covering too many subjects for the first time on a 60 minute call once a week.

  • July 8, 2015
    • Agenda
      • Francois (40min): Extensible Paravirtualized Devices (second half) opnfv-dapcc-extensible_paravirtualized_device.3.pptx
      • Wei&Francois (10min): Gap analysis on MANO descriptors for dpacc {:dpacc:china_mobile_smallcell_gw_acceleration_descriptors_discussion_v2.pptx|}}{
      • All (10min) Planning discussion for upcoming hackfest and potential joint session with ETSI NFV MANO
    • Minutes
      • Extensible Paravirtualized Devices (second half)
        • In the previous part of these slides, Francois presented his extensible para-virtualized device (EPD) design which enables a hybrid "native" access path from the virtio-based vCrypto driver in the guest to the hardware accelerator without the exposure of hardware de
dpacc/meetings.txt · Last modified: 2016/03/20 00:06 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
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki