RE: Further thoughts on uAPI

Hefty, Sean
2016-04-25T16:29:09Z

> Study of objects:
> 'device','port' - Pre-existing and read-only, query_object returns
> information like we have today
> 'pd','mr','mw','cq','srq','qp','ah' - Basic objects, not all have a
> modify/query
> 'flow','xrc',etc - extra objects

IMO, we should examine what items are objects. E.g. and XRC RQ is treated as a QP, whereas an SRQ is not. It may make more sense to treat each QP type as separate objects. It would definitely make the data structures more efficient and a lot more understandable.

> Additional entry points:
> poll_cq/req_notify_cq - These are high speed, so simple ioctls, or
> driver specific
> post recv/send - drivers implement these via call_driver_on_object
> attach/detach mcast - Could be 'modify' a qp, or could be new ioctls
> async_event - Should be an ioctl
> get_fd - Convert the object to a fd (eg async_fd, comp_channel, etc)

We could define a generic event_channel/event_queue object to report asynchronous events. The EQ could then be associated with a device, port, CQ, CM objects (e.g. QP), etc. User space could achieve current semantics by limiting which objects are associated with each channel.