1. DPACC Metadata Update Discussion Lingli Deng 2016/05/05

2. Quick Recap 1/2 New Google doc created for further collaboration https://docs.google.com/document/d/1orUfl93VtRmqTJak9FMQSRO4h1O_V BFG0wuc02Gd97I/edit?usp=sharing https://docs.google.com/document/d/1orUfl93VtRmqTJak9FMQSRO4h1O_V BFG0wuc02Gd97I/edit?usp=sharing Based on previous discussion slides https://wiki.opnfv.org/download/attachments/2926624/2- dpacc_metadata_20160331.pptx?version=1&modificationDate=14593896680 00&api=v2 https://wiki.opnfv.org/download/attachments/2926624/2- dpacc_metadata_20160331.pptx?version=1&modificationDate=14593896680 00&api=v2 Seek convergence with IFA004 on whether to include Context Data format

3. Discussion Points 1.Context/channel/data formats 2.eBNF for string specification 3.acc_capability representation

4. Context & Channels Acceleration resource context: This identifies a specific environment within the acceleration resource such as configuration and state. Acceleration resource contexts allow an acceleration resource to provide state isolation and protection to multiple users sharing the same acceleration resource and allow users to be migrated between different compatible acceleration resources. Whereas a channel is a path to the accelerator that is flow controlled and could have a specific level of service assigned to it. Examples include vrings for SIO-based (virtio) accelerators and SR-IOV DMA rings for HIO-based accelerators. Context_num added. Do we have to also add context as well?

5. Data Format Data format is an indicator to what format the accelerator expects the data to be in before it could process it and what format the accelerator will generate. This is mainly important when VNFs are completely offloaded to hardware accelerators and in case of Chaining (when the output of Accelerator A is to be chained to Accelerator B). The decision of whether those accelerators can be chained “directly” or not will take this into account. Srini: As far as the “Data format” is concerned : I am assuming that Rabi meant the command/response data format between VMs and Accelerators. At this time, IPSec virtio specifications assumes that the accelerators support any host endian- ness. Since hardware accelerators are supposed to work with both little endian and big endian processors, IPSec virtio specification gives guidance on the host byte order to the accelerator as part of virtio device capability negotiation. It is up to the accelerator to do any conversion. Need further confirmation from Rabi and team discussion on whether to add Data Format or not.

6. Use of eBNF for string specification Use eBNF (RFC 5234) for composite string data format definition E.g. device_type [identifier] device_type [data type] Enumeration [representation] device_type = “GPU”| “FPGA” | “ SW” | “ASIC” | “DSP”

7. Representation for acc_capability acc_capability [identifier] acc_capability [data type] structure [representation] A array of Capable Operations, e.g. “encryption”, “decryption”. 1.For each Capable Operation, identify supported configuration sets, e.g. algorithms like “aes”, “3DES” etc. 2.For each Capable Operation under specific configuration setting, specify the capacity of the accelerator. 3.For instance, for AES encryption operation, given 128 bytes input, the throughput metric is 10Gbps.

8. Two options in implementation Option1: in-band pattern exchange ////pattern exchange is combined with value exchange [ 'operation': { 'pattern':'(encryption|decryption)', 'value':'encryption'} 'algorithm':{ 'pattern':'(aes|3des)', 'value':'aes'} 'param':{ 'pattern':'[1-9][0-9]*-[1-9][0-9]*[MGTP]{0,1}bps', 'value':'128-10Gbps'} ] 'param':'128-10Gbps' ] Option2: out-band pattern exchange //Step1: pattern exchange [ 'operation':'(encryption|decryption)'', 'algorithm':'(aes|3des)', 'param':'[1-9][0-9]*-[1-9][0-9]*[MGTP]{0,1}bps' ] //Step2: value exchange [ 'operation':'encryption', 'algorithm':'aes', 'param':'128-10Gbps' ]

9. Todos Convergence with IFA004 Element definition and format specification for non-PCI HW acc Include an example work-through for a selected use-case