OFI SW

Sean Hefty - Intel Corporation

Target Software

www.openfabrics.org 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?

www.openfabrics.org 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

www.openfabrics.org 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

www.openfabrics.org 5

Can we analyze these APIs?

Extending Capabilities to Verbs

struct ibv_qp {<existing fields>struct fid_ep ep;

};

static inline intibv_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);

}

www.openfabrics.org 6

Simple approach(using same name)

New ops embedded into existing structure

Consistent verbs look and feel

qp->ep.fid.msg->sendmem