[Ofvwg] [ANNOUNCE] Open Fabrics Verbs Working Group (OFVWG) meeting tomorrow - 5/3/2016

[Liran Liss]

Hi,

Let's continue the discussion when some more concrete proposals are posted; so no OFVWG meeting tomorrow.
Please find the summary of the last meeting below.

Next meeting planned for 5.17.2016.
Tentative agenda:
- Follow-up on ABI developments
- Generic RSS interface for Raw Ethernet QPs

Thanks,
--Liran

========

ABI notes from 5.3.2016:

The option of encoding an object ID and a method in the ioctl() request code was discussed.
This allows strace to report specific calls as long as the code comprises globally unique tuples. However, the downside is that the object space needs to be partitioned for different uses and would be limited.

There is a general agreement that netlink-style nesting is a good thing, but the flexibility it offers should not be overused for the sake of simplicity. The goal is to have 1-2 attributes per operation, depending on logical grouping of fields. Vendor-specific attributes are nested, and may be as simple as comprising a single binary-packed attribute. Providing globally unique vendor attributes might make the task of attribute validation easier and generic. Need to check if this would continue to hold with optional attributes as well.

The uAPI should map the existing kAPI completely. Partitioning of attributes into groups and introducing typed attributes for addressing should allow the kernel implementation to be optimized. In addition, generic terms that are bound to specific enumerations, such as MTU, could be generalized while still providing backward compatibility.

The option of allowing a vendor to bypass the generic kAPI parsing for specific object/methods was raised as a method to still support generic objects while further optimizing the representation. However, it's not clear if the savings would be substantial, and this prevents objects created this way from interacting with other generic objects and being manipulated in common code paths.

ucma could employ a similar scheme. The possibility of uniting the ucma fd with uverbs was raised as way to simply the code. However, ucma and uverbs stand for different things and have different security contexts. Also, ucma objects are not always associated with a device instance. A new event queue object, which can aggregate events from multiple devices and/or multiple event sources such as device and CM events, could be introduced to simplify application event processing.

First objective is resolve the security issues and to allow the existing user-space code to work. Immediate follow-up extensions should include a granular capability query subsystem and the aforementioned an event queue object.