The reason we're asking for these IBV_*_USNIC enums now -- before we've
submitted the driver -- is because we're targeting getting our driver included
in RHEL 6.5. There's a bit of a chicken-and-egg issue here: they'll accept
our
patches for a new hardware driver while that driver is being
What happens if in the future the IBTA adds new MTUs and allocates those
currently reserved MTU values ? Wouldn't those values need to be
standardized at the IBTA so that conflict won't occur ?
The IBTA needs to standardize the values as they appear in MADs. The software
values can differ.
Even with a map I think having IB_MTU_1500 will cause some confusion as this
is
not an IB MTU. It seems an alternate enum name like RDMA_MTU_1500 is
better.
Couldn't these be usable MTU's for RoCE?
In hindsight, the user space API never should have exposed the mtu as an enum...
Since an
Per off-list conversation with Roland, add some new enums for the
Cisco Ethernet Virtual NIC (it's not an RNIC/iWARP device, so it
doesn't fit in the same category as RDMA_NODE_RNIC / RDMA_TRANSPORT_IWARP).
USNIC = Userspace NIC.
Can we get a better patch description?
Maybe mention
Hi Sean, Ping. You had concerns on the suggested concept, we want to
know if we addressed them, can you comment?
I'm in meetings this week until tomorrow. I'll try to take a look at the
updated patches then or Friday.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
Just wondered why are you setting errno in the mad libraries? so far we
managed to avoid doing so in libibverbs, librdmacm, libmlx4 ones.
The librdmacm does set errno
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
Thanks, it seems that I asked the question in a wrong way.
The context is what I need eventually but in order to find it I first
need to recover the QP or the XRC SRQ.
Per core there may be several QP and SRQ using the same CQ.
When doing ib_poll_cq on the CQ the WQE in hand has only an ib_qp
Just wonder, the Infiniband Annex for XRC uses the terms XRC INI QP
and XRC TGT QP and the kernel include file include/rdma/ib_verbs.h
also defines IB_QPT_XRC_INI and IB_QPT_XRC_TGT so why to use in
include/infiniband/verbs.h other names i.e. IBV_QPT_XRC_SEND and
IBV_QPT_XRC_RECV?
I agree
This is just a workaround I been considering in case using hints and
asynchronous connection request can't work together. If I want to have
servers and clients that need to be backward compatible with RC servers
and clients. And assuming the old ones didn't used the private data in
the
I understand that currently I can't do RDMA using XRC, is that the case?
How complicated are the required modifications needed to make librdmacm
complies to the libibverbs changes?
The changes needed for the librdmacm to support XRC aren't huge. The
complication is getting XRC merged with
I think I missed something here, can I use your branch xrc2 of
libibverbs for testing purpose, or there are still things to merge there?
The xrc2 branch is usable. I'm about 10-15 minutes away from posting v5 of
those patches.
And for librdmacm, I'm looking forward to try it with a real
A natural way to pass the SRQ's QPN is to use the private_data of the
rdma_conn_param, however this area is limited to 56 octets and since
each QPN occupies 3 octets that leaves us with 18 SRQ. I suggest to
increase the size of the private data, or to find a more convenient way
to pass the
In libibverbs/include/infiniband/verbs.h the API ibv_open_xrcd is
defined with the following signature;
static inline struct ibv_xrcd *
ibv_open_xrcd(struct ibv_context *context, struct ibv_xrcd_init_attr
*xrcd_init_attr)
And libibverbs/examples/xsrq_pingpong.c the call is O.K. however in
Here's V3 of the IPoIB TSS/RSS patch series, basically its very similar to
V2,
with fix to for one issue we stepped over while testing V2 and addressing of
feedback provided by Sean on the QP groups concept.
Hi Sean,
Re your feedback on V2, do you feel the concept has been flushed out
I don't see cover-letter for V4 of libibverbs and V3 of libmlx4 patches
you posted over the weekend, would be nice if you
can reply to one of your posting per series and send quick listing of
the changes (if any) from previous versions.
There are no changes from v3.
--
To unsubscribe from
@@ -590,6 +613,11 @@ struct ibv_send_wr {
uint32_tremote_qpn;
uint32_tremote_qkey;
} ud;
+ struct {
+ uint64_treserved[3];
+ uint32_treserved2;
+
If those reserve fields are either A) not correctly set to 0 or B) are used
for
some future status this function will fail. Since the spec says to ignore
them
I would do something like.
status = ntohs(status);
status = 0x001F;
With a #define'd mask for 1F of course...
Define AF_IB and sockaddr_ib to allow the rdma_cm to use native IB
addressing.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
include/linux/socket.h |2 +
include/rdma/ib.h | 89
2 files changed, 91 insertions(+), 0
Are there any examples out there of IB applications that use
RDMA_OPTION_ID_TOS? I'm looking to make this available for iwarp
transports, but I'm still trying to understand how its currently used,
and what values are used. Since this option is level RDMA_OPTION_ID, I
guess it is
+char * umad_class_str(uint8_t mgmt_class);
+char * umad_method_str(uint8_t mgmt_class, uint8_t method);
+char * umad_attribute_str(uint8_t mgmt_class, be16_t attr_id);
+char * umad_mad_status_str(be16_t status, char * buf, size_t len);
Why is umad_mad_status_str() different?
--
To
+char * umad_class_str(uint8_t mgmt_class);
+char * umad_method_str(uint8_t mgmt_class, uint8_t method);
+char * umad_attribute_str(uint8_t mgmt_class, be16_t attr_id);
+char * umad_mad_status_str(be16_t status, char * buf, size_t len);
Why is umad_mad_status_str() different?
These return values seem mutually exclusive. Surely we're not going to see
a
MAD with status 'busy - redirection required - bad version - success'?
They are mutually exclusive now but because the spec defines separate fields
it
might not always be that way. That is what I meant when
+#define UMAD_GENERIC_ATTRIBUTE_STR \
+ case UMAD_ATTR_CLASS_PORT_INFO: \
+ return Class Port Info; \
+ case UMAD_ATTR_NOTICE: \
+ return Notice; \
+ case UMAD_ATTR_INFORM_INFO: \
+ return Inform
This would definitely work but I was concerned that someone reading the header
file would confuse such a function with:
static inline char * umad_attribute_str(uint8_t mgmt_class, be16_t attr_id)
and not get proper decoding.
Anyway, that is what I was thinking. The macro is pretty
ib_read_lat displays RTT latency, while the other lat programs display
RTT/2. Is this intended? Or is read_lat.c/print_report() missing a
divide-by-two?
The tests should measure how long it takes the data to reach the destination.
For writes/sends, that would be RTT/2. For reads, the
On 2/21/2013 2:44 PM, Ira Weiny wrote:
What about QP1? It was my understanding that CM was still required for
RoCE.
Yes, RoCE requires CM support but AFAIK CM doesn't use/require these
interfaces to get send or receive it's MADs.
RoCE is a weird animal in terms of IB management as
+/* RMPP information */
+#define UMAD_RMPP_VERSION 1
+enum {
+ UMAD_RMPP_TYPE_DATA = 1,
+ UMAD_RMPP_TYPE_ACK = 2,
+ UMAD_RMPP_TYPE_STOP = 3,
+ UMAD_RMPP_TYPE_ABORT= 4,
+
+ UMAD_RMPP_FLAG_MASK = 0x07,
I need to check the kernel code, but I believe that the RMPP header is
exposed.
I looked at copy_recv_mad(), and it copies the entire 256-byte MAD to user
space, which includes any RMPP header, followed by any additional segmented
data. So most of the RMPP definitions are relevant, the
How about moving ahead without these for now ? They can always be added
back in when the time is right. If that's acceptable to you, I'll make
that modification myself and move onto the other libibumad patches in
your series.
That's fine.
--
To unsubscribe from this list: send the line
+#define UMAD_GENERIC_ATTRIBUTE_STR \
+ case UMAD_ATTR_CLASS_PORT_INFO: \
+ return Class Port Info; \
+ case UMAD_ATTR_NOTICE: \
+ return Notice; \
+ case UMAD_ATTR_INFORM_INFO: \
+ return Inform
The AF_IB uses a 64-bit service id (SID), which the
user can control through the use of a mask. The rdma_cm
will assign values to the unmasked portions of the SID
based on the selected port space and port number.
Something here I am not sure to follow -- if AF_IB consumers are allowed
Sean, I've lost track of all this over time, but just to check in,
with this new interface, would it be possible to obsolete ib_ucm? That
seems desirable to me, as it is so flawed..
I'd love to obsolete ib_ucm. This interface should make it possible, though
some additional implementation
A long time ago we discussed having different paths for CM GMP,
inbound data and outbound data (ie the full IB asymetric pathing
model), did that get included in the API as well?
Yes - this support made it upstream.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the
On 2/11/2013 9:46 PM, Hefty, Sean wrote:
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -844,10 +844,10 @@ static u32 ipoib_addr_hash(struct ipoib_neigh_hash
*htbl,
u8 *daddr)
* different subnets
My understanding of this is that there's NO changes to the wire protocols.
A QP is simply that, a pair of queues - one send, one receive. To the best
that I can figure out, you're wanting to allocate 'multiple-queues' - something
that has multiple send and receive queues. (I use the term MQ,
The intent would be to construct a single library containing the
core functionality -- data transfers, connection establishment, and
subnet management -- required by most applications. It could target
combining libibverbs, librdmacm, and libibumad APIs.
If you are just going to combine
Define AF_IB and sockaddr_ib to allow the rdma_cm to use native IB
addressing.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
include/linux/socket.h |2 +
include/rdma/ib.h | 89
2 files changed, 91 insertions(+), 0
I wanted to gauge if there was support or opposition in creating a single RDMA
library, librdma.
The intent would be to construct a single library containing the core
functionality -- data transfers, connection establishment, and subnet
management -- required by most applications. It could
The hash function introduced in commit b63b70d877 IPoIB: Use a private hash
table for path lookup in xmit path was designd to use the 3 octets of the
IPoIB HW address that holds the remote QPN. However, this currently isn't
the case under little endian machines as the code there uses the flags
RSS (Receive Side Scaling) TSS (Transmit Side Scaling, better known as
MQ/Multi-Queue) are common networking techniques which allow to use
contemporary NICs that support multiple receive and transmit descriptor
queues (multi-queue), see also Documentation/networking/scaling.txt
If TSS is
So, if you want a cyclic allocation, the allocation should be tried in
[start, END) and then [0, start); otherwise, after the allocation
wraps for the first time, as the closer the starting point gets to
END, the chance of not finding a vacant slot in [start, END) goes
higher. When @start
* drivers/infiniband/core/cm.c:cm_alloc_id()
drivers/infiniband/hw/mlx4/cm.c:id_map_alloc()
Used to wrap cyclic @start. Can be replaced with max(next, 0).
Note that this type of cyclic allocation using idr is buggy. These
are prone to spurious -ENOSPC failure after the first
the mainline kernel -stable process is something else... Sean I assume
you understood what I was up to.
yes
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Reviewed-by: Sean Hefty sean.he...@intel.com
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I updated the patch based on your feedback and pushed the change into my git
tree.
I plan on creating a new release of the librdmacm this quarter that will
contain this fix.
- Sean
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to
Could we somehow also fix or at least catch the issue from librdmacm, e.g.
by checking for uid=0, see the patch below? Probably the patch is not
sufficient, as the event needs to be deleted somehow, is there a way to do
that without further processing it?
Excellent idea! It should be safe to
we got a bug report from a customer that FhGFS server daemons frequently
crash. Looking into it, we are almost sure it is related to
librdmacm/kernel-ib. So the crash in librdmacm resolves to:
(gdb) l *(rdma_get_cm_event+0x102)
0x3d6dc04522 is in rdma_get_cm_event (src/cma.c:1975).
1970
Support for existing UDP applications is done via the rspreload
library. However, when the preload library is loaded, socket
calls used by rsockets get intercepted and converted into
rsocket calls.
The preload library was able to handle this for TCP rsockets
by using a per thread variable and
Is this a bug? I think it is...
diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c
index 2709ff5..fb24f05 100644
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -806,8 +806,13 @@ static ssize_t ucma_accept(struct ucma_file *file,
Add a sample test program to test datagram rsockets. Move
common routines used by udpong and other test programs into
a common source file.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
Makefile.am |8 -
examples/common.c| 93
examples/common.h| 45
Add a sample test program to test datagram rsockets. Move
common routines used by udpong and other test programs into
a common source file.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
Makefile.am |8 -
examples/common.c| 93
examples/common.h| 39 +++
I should have marked this for the librdmacm...
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks - applied.
I'm using a locally modified version of verbs, so I don't end up seeing this
error.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I'm using a locally modified version of verbs, so I don't end up seeing this
error.
could this be related to different results while running netperf .w
fork in our setup vs. yours?
I was referring to the build issue, not the fork problem.
According to my notes, I ran netperf with fork
Was there progress on using rsocket under netperf or fork in general?
Fork support in rsockets is available now, and netperf should work. It's not
generic enough to handle any arbitrary call to fork, but will work if the app
does something like this:
listen()
s = accept()
fork(s)
Do you
Problem reported by Dan Carpenter dan.carpen...@oracle.com:
The patch 3c86aa70bf67: RDMA/cm: Add RDMA CM support for IBoE
devices from Oct 13, 2010, leads to the following warning:
net/sunrpc/xprtrdma/svc_rdma_transport.c:722 svc_rdma_create()
error: passing non neg 1 to ERR_PTR
This
I am working on building an Infiniband application with a server that
can handle many simultaneous clients. The server exposes a chunk of
memory that each of the clients can read via RDMA. I was previously
creating a new MR on the server for each client (and of course in that
connection's
The rdma_cm will automatically allocate one PD per RDMA device. You can
share this PD among multiple connections. To use this PD, pass in NULL into
rdma_create_qp(). The rdma_cm_id will reference the shared PD.
That's great to know; thanks Sean (and everyone else who confirmed
that a
drivers/infiniband/core/ucm.c |2 +-
drivers/infiniband/core/ucma.c|2 +-
On these files, as far as I understand this code from quick looking, I'm
not sure on what
exactly the completion objects protects, Sean?
These protect against the caller trying to destroy
We introduce rsocket extensions for supporting direct
data placement (also known as zero copy). Direct data
placement avoids data copies into network buffers when
sending or receiving data. This patch implements zero
copies on the receive side, but adds some basic framework for
supporting it on
riostream is based on rstream, but uses the new riomap, riounmap,
and riowrite calls instead. It runs a series of latency and
bandwidth tests using remote iomapped memory.
riostream is limited to using zero copy transfers at the
receiving side only at this time.
Signed-off-by: Sean Hefty
For client connections that would work, but it can't work for a server
that uses fork() after listen().
Would it be possible to extend the librdmacm and libibverbs to:
- handle fork() after getting RDMA_CM_EVENT_CONNECT_REQUEST
which means there have to be some functions to destroy
@@ -226,7 +225,7 @@ static struct ibv_device *mlx4_driver_init(const char
*uverbs_sys_path,
return NULL;
found:
- if (abi_version MLX4_UVERBS_MIN_ABI_VERSION ||
+ if (abi_version = MLX4_UVERBS_MIN_ABI_VERSION ||
abi_version MLX4_UVERBS_MAX_ABI_VERSION) {
ABI version 2 is really not supported any more in verbs ext mode.
The idea in this change was to fail the driver registration and not wait that
ibv_cmd_get_context will be called and fail.
See patch for libibverbs.
To have a correct error message we can increase MLX4_UVERBS_MIN_ABI_VERSION
Add an option that allows address and route data to
time out. Once data has timed out, it needs to be
resolved again. This helps handle cases where the
remote data has changed.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
linux/osd.h |4 +++-
src/acm.c | 41
This causes ibacm files to be created as world writable.
Problem reported by Florian Weimer fwei...@redhat.com
Signed-off-by: Sean Hefty sean.he...@intel.com
---
src/acm.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/acm.c b/src/acm.c
index 00fc35d..725cde2
thanks!
Applied all, but with a couple of minor adjustments.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
The librdmacm will try to connect port 6125 if ibacm.port is
not found. The problem is that some other service or application
could be using that port and respond with garbage. Rather
than falling back to a hard coded port number, if ibacm.port
is not found, simply disable ACM support.
This has
retry_count, I assume, is for connection establishment? For the Chelsio
devices, this is all up to the TCP stack and thus this counter is not
used. If there is no TCP listener, then the connection establishment
will fail immediately. If the node is not reachable, then normal TCP
retransmit
When ucmatose aborts because of issues trying to connect
to the server, it moves to disconnecting all connections.
However, not all connections may have been established.
The result is that ucmatose will hang in disconnect_events.
Fix this by setting the number of times that we need to
disconnect
I'm looking for brilliant ideas on the best way to support UDP type
applications over rsockets. The specific problem that needs to be address is
how to convert:
sendto( ... dest_addr ..)
into
resolve IP address to IB address (rdma_resolve_addr)
obtain path record (rdma_resolve_route)
convert
Bonus points if you can handle the UDP server stopping and restarting.
Do any of the existing HCAs prevent one from requesting a specific QPN on
creation, or is this merely a software restriction?
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message
I think the RDS code achieves effectively this (though it has state
keeping structures in the kernel, a luxury rsockets does not).
Possibly some inspiration could be gleaned from their approach?
I've thought of RDS as well. RDS maintains an active connection to every
remote node, with data
1) rping, on the client side, clears the conn_params for the newly to be
attempted connection, then sets:
conn_param.responder_resources = 1;
conn_param.initiator_depth = 1;
conn_param.retry_count = 10;
2) the qib driver enforces a maximum of 7 for retry_count. I don't
1) rping, on the client side, clears the conn_params for the newly to be
attempted connection, then sets:
conn_param.responder_resources = 1;
conn_param.initiator_depth = 1;
conn_param.retry_count = 10;
2) the qib driver enforces a maximum of 7 for retry_count. I don't
Jason - Like your idea for full APM support especially across subnets, but
wouldn't that require some sort capability that lives above the subnet level
and is able to query both SMs/SAs? Sounds vaguely router-ish?
I'm guessing that it would require that the ports involved have different GIDs
Just a crazy thought but IPoIB could use RDMA-CM for all of its
connection management stuff..this way it can leverage the APM support in
RDMA-CM..
comments?...
ipoib predates the rdma cm, which is why it's written to the ib_cm directly.
Communication setup with the rdma cm follows these 3
change from v2:
Added a has_comp_mask field to verbs_context
Did I miss something? It never gets used, and never gets set in the
mlx4 patches?
I think I sent a non-updated patch mlx4 patch 2 - it should be set there. I'll
resend that patch.
--
To unsubscribe from this list: send the
Did I miss something? It never gets used, and never gets set in the
mlx4 patches?
I think I sent a non-updated patch mlx4 patch 2 - it should be set
there. I'll resend that patch.
Do you have a git server you can put them up on? github?
git.openfabrics.org/~shefty/libmlx4.git
+enum verbs_xrcd_mask {
+ VERBS_XRCD_HANDLE = 1 0,
+ VERBS_XRCD_RESERVED = 1 1
+};
I think it would be a good idea to make both of these constants
(10), the '0' serves as an ABI rev, not an individual field. That
will give a bit more life to this system, and it makes
+static inline uint32_t ibv_get_srq_num(struct ibv_srq *srq)
+{
+ struct verbs_context *vctx = verbs_get_ctx_op(srq-context,
get_srq_num);
+ if (!vctx) {
+ errno = ENOSYS;
+ return 0;
+ }
+ return vctx-get_srq_num(srq);
+}
Do you think the
XRC introduces several new concepts and structures, one of
which is the XRC domain.
XRC domains: xrcd's are a type of protection domain used to
associate shared receive queues with xrc queue pairs. Since
xrcd are meant to be shared among multiple processes, we
introduce new APIs to open/close
Signed-off-by: Sean Hefty sean.he...@intel.com
---
man/ibv_open_qp.3 | 50 ++
1 files changed, 50 insertions(+), 0 deletions(-)
create mode 100644 man/ibv_open_qp.3
diff --git a/man/ibv_open_qp.3 b/man/ibv_open_qp.3
new file mode 100644
index
From: Yishai Hadas yish...@mellanox.com
Signed-off-by: Yishai Hadas yish...@mellanox.com
Signed-off-by: Tzahi Oved tza...@mellanox.com
Signed-off-by: Sean Hefty sean.he...@intel.com
---
src/mlx4.c | 103 ++--
src/mlx4.h | 16 +
2
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,
XRC receive QPs are shareable across multiple processes. Allow
any process with access to the xrc domain to open an existing
QP. After opening the QP, the process will receive events
related to the QP and be able to modify the QP.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
Based on a patch from Yishai Hadas yish...@mellanox.com
Infrastructure to support extended verbs capabilities in a forward/backward
manner.
Support for extensions is determined by the provider calling
verbs_register_driver in place of ibv_register_driver. When
extensions are enabled, ibverbs
Signed-off-by: Sean Hefty sean.he...@intel.com
---
src/buf.c |6 +-
src/cq.c | 40 +++---
src/mlx4-abi.h |6 ++
src/mlx4.c | 21 +++--
src/mlx4.h | 64 +++-
src/qp.c | 39 ++
src/srq.c | 151
From: Jay Sternberg jay.e.sternb...@intel.com
Signed-off-by: Jay Sternberg jay.e.sternb...@intel.com
Signed-off-by: Sean Hefty sean.he...@intel.com
---
Makefile.am |4
examples/xsrq_pingpong.c | 885 ++
2 files changed, 888
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,
diff --git a/src/cq.c b/src/cq.c
index 8f7a8cc..20ce1f1 100644
--- a/src/cq.c
+++ b/src/cq.c
@@ -220,33 +220,43 @@ static int mlx4_poll_one(struct mlx4_cq *cq,
rmb();
qpn = ntohl(cqe-vlan_my_qpn) MLX4_CQE_QPN_MASK;
+ wc-qp_num = qpn;
is_send =
Signed-off-by: Sean Hefty sean.he...@intel.com
---
man/ibv_open_qp.3 | 50 ++
1 files changed, 50 insertions(+), 0 deletions(-)
create mode 100644 man/ibv_open_qp.3
diff --git a/man/ibv_open_qp.3 b/man/ibv_open_qp.3
new file mode 100644
index
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,
From: Jay Sternberg jay.e.sternb...@intel.com
Signed-off-by: Jay Sternberg jay.e.sternb...@intel.com
Signed-off-by: Sean Hefty sean.he...@intel.com
---
Makefile.am |4
examples/xsrq_pingpong.c | 880 ++
2 files changed, 883
XRC receive QPs are shareable across multiple processes. Allow
any process with access to the xrc domain to open an existing
QP. After opening the QP, the process will receive events
related to the QP and be able to modify the QP.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
changes from
Implement the libibverbs xrc support using the defined xrc
extensions.
This patch is based on a patch by Jack Morgenstein.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
src/buf.c |6 +-
src/cq.c | 40 +++---
src/mlx4-abi.h |6 ++
src/mlx4.c | 21 +++--
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,
From: Yishai Hadas yish...@mellanox.com
Signed-off-by: Yishai Hadas yish...@mellanox.com
Signed-off-by: Tzahi Oved tza...@mellanox.com
Signed-off-by: Sean Hefty sean.he...@intel.com
---
changes from v1:
There's no longer a need for alloc_context to return -1, so kept alloc_context
and
Patch adapted from Yishai Hadas yish...@mellanox.com
Infrastructure to support extended verbs capabilities in a forward/backward
manner.
Support for extensions is determined by the provider calling
verbs_register_driver in place of ibv_register_driver. When extensions
are enabled, ibverbs sets
XRC introduces several new concepts and structures, one of
which is the XRC domain.
XRC domains: xrcd's are a type of protection domain used to
associate shared receive queues with xrc queue pairs. Since
xrcd are meant to be shared among multiple processes, we
introduce new APIs to open/close
401 - 500 of 1258 matches
Mail list logo
