October 28, 2015
Minutes
follow-up discussion on flow-
API (passed for absence of major contributor of this proposal)
-
Cleaned up business requirements and portability requirements sections
Created performance metrics and testing section for further input
Stopped at the last two items of opensource requirements section
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.
September 23, 2015
Agenda
Minutes
-
-
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.
-
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.
-
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.
-
-
September 9, 2015
Agenda
Minutes
B-release planning update
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.
-
-
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.
-
August 12, 2015
Agenda
Minutes
discussing, commenting and dealing with questions on Keith’s DPDK slide deck
-
Question was asked about how DPDK could support other acceleration hardware.
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.
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.
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.
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.
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.
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 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
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
2015: documentation & demo ('demo' was advised to be changed to PoC or Prototype during the call)
2016: code integration
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:
(a) 'demo' may have referred to the results of PoC(s) proposal(s) for g-
API, binary compatibility (virtio) etc to meet requirements, and…
(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
-
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