• Update Summary for api guidelines
  • (postponed to next week) Nomad SB API(Tentative)

Lingli, Howard, Keith, Arei, Denis, Rajesh, Paul, Varun, Arun, Mike, Michele

1. Address: For example, Bar address for PCI device (via IO configuration). Need further examples for non-PCI device (e.g. mem address).
2. Vendor-ID/Device-ID: Mike: 0 for SW acc is a common practice. Varun: not sure it is the case. Lingli: Do we differentiate software accelerators from different vendors?
3. Varun: no sure why VNF needs to be aware of the vendor-id or device-id of the HW acc? Lingli: this is for mgmt agent rather than VNF applications.
4. Lingli: call for input for non-PCI device and SW acc.
5. Mike: where does the requirement for metadata come from?
   1. Lingli: refer to gap analysis on openstack for dpacc.

• Update Summary
• dpacc work items
• new doc for api guidelines

1. No update to dpacc arch and openstack gap or use-case
2. A slide for addresing a comment on use-case doc is provided
3. * Reference to the arch doc is used to clarify that the PDCP usecase in the usecase doc is aligned with the dpacc arch.
4. * Lingli will put the comment and reply online and contact original commenter Ola for further confirmation if the concern is addressed or not.

• api guidelines

• Do we need to remove the “accmodel” name ?
  • Keith: suggest to remove model information from api name and insert it the arguments instead.
  • Ola: It is ok to have the model name in the API, as the application is aware of the accelerator type.
  • Denis: It is better to have the model name in the API name because the API is different for different models. For example encap_packet for lookaside has to supply output buffers, whereas encap_packet for inline does not have to supply them. _accmodel_ can be dropped in the API. Merits in dropping
  • Mike: need further clarifications on the necessity of removing accmodel from API name.
  • Lingli: both ways are technically sound, the motive is to keep the API suite as simple as possible, and as general as possible across different usecases.
  • offline discussion: API implementation is mostly same for different accmodel. E.g., g_ipsec_la_add_sa() and g_ipsec_inline_add_sa(). An implementor anyway would internally use same API. To control the few steps which are different in such API, we can either Capture accmodel in the device structure during device open and use it (preferred) Or pass accmodel as argument in the API (in the worst case)
• Agreed to move it from the API name to arguments, with more clarification.

• Operations of "set" and "modify"
  • Keith: what is the difference between "set" and "modify"?
  • Rajesh: Set API is used to update the global configuration like Hostname,time etc., get/set API's operations are used in sequence. There won't be delete API call for this set of API's, as it has always some global value. To configure the new record, add/modify/delete API's are used.
  • Denis: set API is used for setting global parameters of the driver or accelerator. modify api is used to change an existing IPsec SA or PDCP security context. Right now, we do not have an example for set API.
• Agreement: The verb ‘set’ is preferred because it better aligns with ‘get’. Eliminates the verb ‘modify’, minimizing the number of verbs.

• Revised Design Proposal: The error code is a 32 bit number constructed as follows
  • Error codes are negative, except when return is successful when the error code is 0
  • Positive return values may be used to indicate other non-error return values such as number of packets processed in a multi_packet call.  These return values are common to all accelerators.
  • The most significant 16 bits is the accelerator ID assigned by a global registry.(Shall we set up such a registry?)
  • The least significant 16 bits is the error code. Common error codes applicable to all accelerators, which should be assigned by a global registry.
  • ACCELERATOR_COMMON_ERROR_CODE_MAX is defined to reserve and define the commonly used error codes.
  • ccelerator specific errors should start from COMMON_ERROR_CODE_MAX.
• Additional suggestions from Keith
  • Document and ensure in the driver that the positive return values do not exceed (2**31 – 1)
  • Change ACCELERATOR_COMMON_ERROR_CODE_MAX to 0xFF (255)

It is proposed to Removed cb_arg_len field. Keith: Instead of having per API callback with different arg list, can we use a single callback function for all API specified by application during device open, with fixed number of arguments? Keith: the argv list for the callback could be fixed or variable using varargs if that makes it simpler. The varargs code does add some complexity, but maybe it is worth using. Denis/Rajesh: Study the possibility and get back

discussion slides

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

1. API Guidelines:
   1. Revise the current doc to address current comments.
   2. Need Global Registry for acc ID to be referenced in errcodes
2. Meta Data:
   1. Contact author of IFA004 for further clarifications on Number of Contexts/Data Format.
   2. Need further input on various element/format specifications for non-PCI accelerators.
3. Initiate C-release planning discussion