Sean Hefty [Mon, 17 Sep 2012 23:00:12 +0000 (16:00 -0700)]
libibverbs: Add support for XRC QPs
XRC queue pairs: xrc defines two new types of QPs. The
initiator, or send-side, xrc qp behaves similar to a send-
only RC qp. xrc send qp's are managed through the existing
QP functions. The send_wr structure is extended in a back-
wards compatible way to support posting sends on a send xrc
qp, which require specifying the remote xrc srq.
The target, or receive-side, xrc qp behaves differently
than other implemented qp's. A recv xrc qp can be created,
modified, and destroyed like other qp's through the existing
calls. The qp_init_attr structure is extended for xrc qp's.
Because xrc recv qp's are bound to an xrcd, rather than a pd,
it is intended to be used among multiple processes. Any process
with access to an xrcd may allocate and connect an xrc recv qp.
The actual xrc recv qp is allocated and managed by the kernel.
If the owning process explicit destroys the xrc recv qp, it is
destroyed. However, if the xrc recv qp is left open when the
user process exits or closes its device, then the lifetime of
the xrc recv qp is bound with the lifetime of the xrcd.
Sean Hefty [Mon, 17 Sep 2012 23:00:12 +0000 (16:00 -0700)]
libibverbs: Add support for XRC QPs
XRC queue pairs: xrc defines two new types of QPs. The
initiator, or send-side, xrc qp behaves similar to a send-
only RC qp. xrc send qp's are managed through the existing
QP functions. The send_wr structure is extended in a back-
wards compatible way to support posting sends on a send xrc
qp, which require specifying the remote xrc srq.
The target, or receive-side, xrc qp behaves differently
than other implemented qp's. A recv xrc qp can be created,
modified, and destroyed like other qp's through the existing
calls. The qp_init_attr structure is extended for xrc qp's.
Because xrc recv qp's are bound to an xrcd, rather than a pd,
it is intended to be used among multiple processes. Any process
with access to an xrcd may allocate and connect an xrc recv qp.
The actual xrc recv qp is allocated and managed by the kernel.
If the owning process explicit destroys the xrc recv qp, it is
destroyed. However, if the xrc recv qp is left open when the
user process exits or closes its device, then the lifetime of
the xrc recv qp is bound with the lifetime of the xrcd.
Sean Hefty [Mon, 17 Sep 2012 23:00:12 +0000 (16:00 -0700)]
libibverbs: Add support for XRC QPs
XRC queue pairs: xrc defines two new types of QPs. The
initiator, or send-side, xrc qp behaves similar to a send-
only RC qp. xrc send qp's are managed through the existing
QP functions. The send_wr structure is extended in a back-
wards compatible way to support posting sends on a send xrc
qp, which require specifying the remote xrc srq.
The target, or receive-side, xrc qp behaves differently
than other implemented qp's. A recv xrc qp can be created,
modified, and destroyed like other qp's through the existing
calls. The qp_init_attr structure is extended for xrc qp's.
Because xrc recv qp's are bound to an xrcd, rather than a pd,
it is intended to be used among multiple processes. Any process
with access to an xrcd may allocate and connect an xrc recv qp.
The actual xrc recv qp is allocated and managed by the kernel.
If the owning process explicit destroys the xrc recv qp, it is
destroyed. However, if the xrc recv qp is left open when the
user process exits or closes its device, then the lifetime of
the xrc recv qp is bound with the lifetime of the xrcd.
Sean Hefty [Wed, 12 Sep 2012 18:32:27 +0000 (11:32 -0700)]
libibverbs: Support older providers that do not support extensions
In order to support providers that do not handle extensions, including
providers built against an older version of ibverbs, add a compatibility
layer. This allows most of the core ibverbs code to assume that
extensions are always available. The compatibility layer is responsible
for converting between the extended verbs and the current structure
definitions.
The compatibility layer allows applications to make use of extended
structures, independent of the provider supporting them, and allows us
to extend existing structures which are normally allocated by the
provider: ibv_qp, ibv_srq, ibv_ah, ibv_mr, ibv_cq, ibv_pd, ibv_mw,
and ibv_comp_channel. Existing applications are unaffected.
The compatibility layer is similar to the 1.0 compat code. It allocates
the extended structures, which then point to the ones allocated by the
provider. For the most part, the compatibility code is invoked by
directing the ibv_context ops into a compat function, which then redirects
the call to the provider. This results in one extra level of indirection
when running with a provider that does not support extensions.
The exceptions to the indirection are opening and closing a device and
handling asynchronous events.
Sean Hefty [Wed, 12 Sep 2012 18:32:27 +0000 (11:32 -0700)]
libibverbs: Support older providers that do not support extensions
In order to support providers that do not handle extensions, including
providers built against an older version of ibverbs, add a compatibility
layer. This allows most of the core ibverbs code to assume that
extensions are always available. The compatibility layer is responsible
for converting between the extended verbs and the current structure
definitions.
The compatibility layer allows applications to make use of extended
structures, independent of the provider supporting them, and allows us
to extend existing structures which are normally allocated by the
provider: ibv_qp, ibv_srq, ibv_ah, ibv_mr, ibv_cq, ibv_pd, ibv_mw,
and ibv_comp_channel. Existing applications are unaffected.
The compatibility layer is similar to the 1.0 compat code. It allocates
the extended structures, which then point to the ones allocated by the
provider. For the most part, the compatibility code is invoked by
directing the ibv_context ops into a compat function, which then redirects
the call to the provider. This results in one extra level of indirection
when running with a provider that does not support extensions.
The exceptions to the indirection are opening and closing a device and
handling asynchronous events.
Sean Hefty [Mon, 17 Sep 2012 19:34:55 +0000 (12:34 -0700)]
livibverbs: Add support for XRC SRQs
XRC support requires the use of a new type of SRQ.
XRC shared receive queues: xrc srq's are similar to normal
srq's, except that they are bound to an xrcd, rather
than to a protection domain. Based on the current spec
and implementation, they are only usable with xrc qps. To
support xrc srq's, we define a new srq_init_attr structure
to include an srq type and other needed information.
The kernel ABI is also updated to allow creating extended
SRQs.
Sean Hefty [Mon, 17 Sep 2012 19:34:55 +0000 (12:34 -0700)]
livibverbs: Add support for XRC SRQs
XRC support requires the use of a new type of SRQ.
XRC shared receive queues: xrc srq's are similar to normal
srq's, except that they are bound to an xrcd, rather
than to a protection domain. Based on the current spec
and implementation, they are only usable with xrc qps. To
support xrc srq's, we define a new srq_init_attr structure
to include an srq type and other needed information.
The kernel ABI is also updated to allow creating extended
SRQs.
Sean Hefty [Mon, 17 Sep 2012 19:34:55 +0000 (12:34 -0700)]
livibverbs: Add support for XRC SRQs
XRC support requires the use of a new type of SRQ.
XRC shared receive queues: xrc srq's are similar to normal
srq's, except that they are bound to an xrcd, rather
than to a protection domain. Based on the current spec
and implementation, they are only usable with xrc qps. To
support xrc srq's, we define a new srq_init_attr structure
to include an srq type and other needed information.
The kernel ABI is also updated to allow creating extended
SRQs.
Sean Hefty [Mon, 17 Sep 2012 19:34:55 +0000 (12:34 -0700)]
livibverbs: Add support for XRC SRQs
XRC support requires the use of a new type of SRQ.
XRC shared receive queues: xrc srq's are similar to normal
srq's, except that they are bound to an xrcd, rather
than to a protection domain. Based on the current spec
and implementation, they are only usable with xrc qps. To
support xrc srq's, we define a new srq_init_attr structure
to include an srq type and other needed information.
The kernel ABI is also updated to allow creating extended
SRQs.
Sean Hefty [Mon, 17 Sep 2012 19:34:55 +0000 (12:34 -0700)]
livibverbs: Add support for XRC SRQs
XRC support requires the use of a new type of SRQ.
XRC shared receive queues: xrc srq's are similar to normal
srq's, except that they are bound to an xrcd, rather
than to a protection domain. Based on the current spec
and implementation, they are only usable with xrc qps. To
support xrc srq's, we define a new srq_init_attr structure
to include an srq type and other needed information.
The kernel ABI is also updated to allow creating extended
SRQs.
Sean Hefty [Mon, 17 Sep 2012 19:34:55 +0000 (12:34 -0700)]
livibverbs: Add support for XRC SRQs
XRC support requires the use of a new type of SRQ.
XRC shared receive queues: xrc srq's are similar to normal
srq's, except that they are bound to an xrcd, rather
than to a protection domain. Based on the current spec
and implementation, they are only usable with xrc qps. To
support xrc srq's, we define a new srq_init_attr structure
to include an srq type and other needed information.
The kernel ABI is also updated to allow creating extended
SRQs.
projects / ~shefty / libibverbs.git / log