OFI SW Sean Hefty - Intel Corporation

Target Software 2 Verbs 1.x + extensions 2.0 RDMA CM 1.x + extensions 2.0 Fabric Interfaces “2.0 APIs” ULPs rsockets ES-API … Eventually need to reach consensus on short-term and long-term objectives Options are not mutually exclusive For now, identify common areas

Software Packaging Existing packages –libibverbs, librdmacm, ibacm, libibumad, providers –other packages - PSM, MXM, CoreDirect, DAPL, CCI Modify existing or introduce new packages –How to handle provider packages? –Work with existing or require updates? 3 IB management being addressed separately (e.g. ibssa, ibacm) Focus on how, not necessarily what

Scalable Interfaces Providing optimized SW paths to HW The conceptual model that’s been described –Application identifies API usage model at initialization –Provider selects optimal software path –Object-oriented API model Calls per object, not per provider 4 OFI SW appears to mostly agree on: Disagreement stems from how those APIs are accessed

Object Interfaces Focus on agreement areas –Defined operations, control flags –‘fabric interface’ objects are basically a collection of function pointers QP ~ endpoint –Ops: msg, rma, tagged, atomic, [cm], [triggered] CQ ~ event queue –Ops: ec 5 Can we analyze these APIs?

Extending Capabilities to Verbs struct ibv_qp { struct fid_ep ep; }; static inline int ibv_post_smsg(struct ibv_qp *qp, const void *addr, uint32_t length, uint32_t lkey, void *wr_id) { return fi_sendmem(&qp->ep.fid, addr, length, lkey, wr_id); } 6 Simple approach (using same name) New ops embedded into existing structure Consistent verbs look and feel qp->ep.fid.msg->sendmem