• Update summary
• Dpacc mgmt Metadata
• (postponed to next week) Nomad SB API(Tentative)

Lingli, Keith, Rajesh, Howard, Barat, Ola, Mario, Paul, Arun, Mike

• Update summary
• dpacc work items

• Bob suggested to explicitly state AC is required, Lingli agreed and proposed to add a sentence for that.
• Keith to confirm the changes to Section 2.2.
• Plan to migrate to gerrit next week.

• No new input this week. Renaming issue raised online, decided to stick to the current name.
• Plan to bring to review after completion of Section 5 next week.

• Add Ran terms into terminology section.
• Add two figures for e2e mobile traffic path to clarify the relationship between different applications.
  • Ola and Lingli agreed that there is no limit on separating physical implementation for different applications.
  • E.g. Although we use separate sections for IPSec tunneling acc and PDCP acc, these two functionalities can be implemented by a single physical accelerator and be leveraged by potentially different VNFs or different processing functions of a single VNF running on top of a local compute node.
  • A further note was added later to clarify the idea.
• Refine LTE stack figure to address Ola's comment.
  • Agreed on the change.
  • Ola: What is F1 or F2 for? Rajesh: basic routing function.
  • Ola: are you indicating that virtio-only proposal in dpacc. Lingli/Rajesh/Arun: No.

• Refine figures for IPSec LA acc and PDCP LA acc in Section 5.
  • Lingli suggested devide the long curve of PDCP traffic path into numbered steps. Rajesh further updated the figure.
  • Agreed on the change.
  • Ola: SW accelerator for PDCP in the host? VNF can contain a SW accelerator itself.
  • Rajesh: SW implementation in the host for a backup if no HW accelerator is present, in case of migration.
  • Arun: live migration mechanism discussion later (previous contribution from Subha and Srini).

1. DPACC Arch: Keith acked he would review and confirm the changes to Section 2.2. Migration to gerrit.
2. Gap of OpenStack: Complete Section 5 and finalize the draft on Google doc.
3. DPACC Use-cases: Keep on working description of existing applications/use-cases/figures. Discussion on live migration support/mechanism.

• Dpacc mgmt Metadata

• Device Type: It is agreed that SoC as a collection of accelerators, each of which should be associated with device_id, type, etc., is not to be defined as single device type.
• Acceleration Capability:
  • Ola prefer to use "capacity" rather than capability for performance metrics
  • Lingli clarified that capability is the combination of features and corresponding performance metrics
• Queue Number/Type: It is a little confusing using the term "queue", shall we use channels instead?
• Address:
  • there is no accessible address for SW accelerator, so the Address would be only applicable to HW accelerator, which also means it is an Optional elements rather than mandatory.
  • It should be the bar address for PCI device (via IO configuration)
  • Need to figure out how to define and get the address for non-PCI accelerators.
• Physical Address: Keith suggested it to be grouped into Address, also as an optional element under address.
• Vendor/Product ID: Need to figure out how to define and get the information for non-PCI accelerators.

• Acceleration Capability: Keith suggested to use json to illustrate the data format.
• Need to figure out how to define/specify/convey information on dev_id, address, vendor_id or product_id for non-PCI device.

Howard as the author of IFA004, recommended to cover the requirements into the metadata definition. Although some of the requirements are already covered by the current proposal, others remain unclear and awaits further discussion:

• Version: Rajesh suggested to add version information for accelerators features/capability. Keith further added that there need to be also information about the version of the metadata specification.
• Allow Migration: Consider to be an Optional information element.
• Number of Contexts/Data Format: Do not know their meanings clearly. Suggest to contact the author and consider inclusion afterwards.
• Resource Availability: Not suitable for inclusion into static metadata.

1. Revise the proposal to address current comments.
2. Contact author of IFA004 for further clarifications on Number of Contexts/Data Format.
3. Need further input on various element/format specifications for non-PCI accelerators.

discussion slides

Skipped due to time limit, postponed to next week's call.