• (10min) Drafts Update Summary arch usecase gap_openstack
• (20min) g-API guidelines discussion
• (20min) Nomad SB API discussion

Lingli, Keith, Yannan, Denis, Rajesh, Howard, Barat, Mario

• discussion slides
• work-in-progress

Instead of mandating AC, the proposed updated doc mandates SAL as required. The following sentences are added to clarify that we need SAL, which includes AC, in the aggregated view.

SAL is the software to hardware abstraction layer, which makes possible additional services which can be controlled by the orchestration layer. SAL can be deployed to either guest or host. SAL is required in all DPACC usages identified in this document.

Changes are proposed to both the figures and the text in Section 2.2.1 and 2.2.2, in order to clarify the correspondence between these two parts. The proposal is to use Section 2.2.1 to identify two usage types, each of which is with options and can be further instantiated with several usage examples. Some of the examples of the two usage types are illustrated in the following Section 2.2.2. But the intention is not to change what we have already agreed on for the usage examples.

Due to the time limit, Lingli suggested authors and contributors to review these changes after the meeting and leave comment online. Keith acked he would review and confirm the changes.

• discussion slides
• work-in-progress

Yannan refined the figure of the LTE stack, according to Vineet' comment to differentiate the control plane and data plane towards S1 interface. Keith suggested adding terminology section and define the wireless terms in this figure. Yannan could help with the wireless terms.

Updated figures for virtio look-aside acceleration in Section 3 are confirmed. Started update discussion for subsequent figures virtio-ipsec-la (Denis) and virtio-pdcp-la in Section 5.

Lingli suggested to define NFVI packet processing case in Section 4, and depicted with a single box, like crypto, in other figures of Section 5. Discussion on how to reflect the cases of g-API, SAL and legacy kernel API usages in the figures.

1. Figure update: Denis would update ipsec-la and Rajesh would update pdcp-la figures in Section 5.
2. RAN Terminology: Yannan would help add definitions for RAN terms in Terminology Section.

• discussion slides
• work-in-progress

Fault Detection for accelerators (MUST) Reclaim of accelerators allocated to faulty VMs (MUST) Automatic detection and recovery of faulty agent (MAY) Fault Analysis or Problem Diagnosis for acceleration resources (MAY)

Gaps are to be added next week after the consensus on the requirements statement.

The metedata example table is suggested to be removed from the doc, and serve as the basis for a separate discussion thread dedicated to DPACC metadata to be started next week.

• For Current draft

1. Finalize text for Section 5.
2. Address remaining issues/comments.

• New Threads

1. S-API for dpacc mgmt. discussion
2. Metadata for acceleration resource

• common gapi discussion

• Rajesh presented the management APIs respectively for virtio-pdcp and virtio-ipsec proposals, and identified three “common” APIs, which share the same generic functionalities but different in specific parameters. The suggestion is not to try to design another layer of common APIs for different usecases, as they differ fundamentally in the control/data format to be conveyed.
• Lingli clarified the vision was actually a guidelines for virtio-xxx spec/proposal, which contains basic functionality description of the high level APIs (which could be instantiated by specific APIs in each usecase) but shared the same design philosophy or pattern.
• Rajesh agreed to have the common design patterns for the g-API’s instead of common API’s, and made an initial contribution based on Subha and Srini’s earlier proposal. https://wiki.opnfv.org/_media/dpacc/api_guidelines_01.pdf

1. post the initial draft of guidelines to list review.