Edited by Lingli Deng based on notes taken by Bob Monkman and feedback from Bill Fischofer and Keith Wiles

Bob Monkman Bill Fischofer Keith Wiles Fu Qiao (CM) Srini Addepalli (FreeScale) Subha Venkataraman (Freescale) Bharat Mota (Freescale) Yu Chang (Huawei) Abdel rabi (Altera) Hu Yun Chao (Huawei) Zhou Nan (Huawei) Kin-Yip Liu (Cavium) Brian Skerry (intel) Prakash Kanthi (DataTap Solutions)

Session was delayed until 3:40 and so we had only slightly less than 2 hours. Skipped High level requirements to go over 2 presentations:

1. ODP overview and how it relates to g-API from ODP team perspective.
2. Keith’s updated DPDK perspective g-API presentation

We had presentation, some comments and questions in discussion afterwards.

It is suggested that ODP was created from the start to have precisely the same goal as g-API. Application portability with leverage of differentiated accelerators for different vendors

It is emphasized as the ODP team considers it fundamentally important that representative competitors work together to arrive at the g-API recommendations in the end. And the case for ODP is pretty promising. 30 months in the making and key aspect of ODP is that competitors and partners alike, from OEMs (Cisco, Nokia, ZTE, Huawei), SoC vendors (Applied Micro, AMD, Broadcom, Cavium, EZChip, Freescale, Kalray) and ISVs such as MontaVista, Enea worked in concert to define and agree the APIs, create implementations and a set of 10+ demos over time. Even Intel has been represented, first from OEMs who have a stake in DPDK and Intel Architecture solutions, and now through Wind River just ramping up participation thru acquisition.

Question came up as to 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. "Today we have PowerPC, MIPS and a ARM port to the Gene-X platform. We do not have access to the SoC vendor acceleration hardware since none of the SDK’s are open, but the changes would be very small."

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.

• Bob noted that this is does not have to be the case, but since unlike DPDK, which is in its core software-centric, the SoC specific implementations leverage hardware that is unique to every SoC and may reveal sensitive silicon details if fully published.
• Keith clarified that DPDK is not purely software-centric as the design allows for leveraging hardware as it does support acceleration of crypto, compression, classification/steering etc. has its own hardware designs for crypto, compression and switching. The API caller may choose to one of multiple implementations – either hardware or software. "As an example, we have crypto that is accelerated both via instructions as well as via offload accelerators – whether they be QAT or Nitrox. The only reason we have software designs is the power capability of the IA core allows us to perform some operations in software equally effectively without having to use external hardware. We don’t assume that the platform has hardware accelerators – but we can leverage them if they are there. Adding more support to DPDK to leverage things like external memory and event systems is a long term goal."
• Kin-Yip argued that it was not necessarily mandatory that implementations not be published. Matter of choice.
• Keith opined that it should be possible to publish considerably more without revealing proprietary information (paraphrased).
• Bill remarked that releasing the SDK source should not be an IP (Intellectual Property) problem. Because SDK software is not the secret sauce or IP of the product, the hardware is. “But they are allowed to release whatever source code they wish as no one can force them into doing anything. For a while, there were a few poll-mode drivers on DPDK that were not public, or were binary only. So secret sauce, even if it is in software can be accommodated."

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 all of the current DPDK customers, as would be required to rewrite their VNF applications to address the portability issues. “I would expect most would continue down the current DPDK path and then we have a fragmented world. Having ODP/SoC SDK at the driver layer only makes sense as this is the correct location for these types of drivers plus not effecting the performance of DPDK applications. If the ODP layer is truly not effecting performance then running ODP as a PMD would not effect the SoC performance as well.” *

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.

Bob confirmed the ODP is adding better DPDK support in ODP and will likewise produce some prototype/POCs for assessment of the project. This can be considered part of the Implementation phase where proposals are presented for meeting the requirements of DPACC and the group can evaluate and go from there.

Keith suggested rather than working with DPDK as the SDK to ODP, the team should focus on adding the missing parts to DPDK to enable the ODP/SoC vendors.

• "To be frank, I do not see the need to continue the work with DPDK as the SDK to ODP. This model is not going to be acceptable as too many DPDK users would be required to change and would effect performance on IA platforms. Even if ODP met the 2% performance goal it would still be a hard sell to our customer who already get 100% performance for their applications."
• "With that stated, I would suggest we focus on adding the missing parts to DPDK to enable the ODP/SoC vendors. Meaning we need a port of DPDK to an ARM SoC platform we can all agree on plus we can agree the port is correctly done to not effect ARM/SoC performance. Using the ODP PMD layer will allow the SoC vendors to keep their IP private and still produce an open source solution."
• "We can then move forward in the DPACC with a common goal for the VNF applications."