At the time when peer closes connection, iw_cxgb4 will not
send a cq event if ibqp.uobject exists. In that case, its possible
for user application to get blocked in ibv_get_cq_event.
To resolve this, call the cq's comp_handler to unblock any read
from ibv_get_cq_event.
Signed-off-by: Kumar
Hi Karl,
The idea in that if the received event is = OSM_EVENT_ID_MAX,
then the plug-in knows that something went wrong (wrong version,
something changed in API, etc).
Also, you might want to know about more stuff if you're pulling
topology/routing info from SM, such as when SM became
Acked-by: Steve Wise sw...@opengridcomputing.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
Would this generate a completion event even if no completion entries are queued?
Maybe I'm misunderstanding, but this sounds like a bandaid for broken
applications,
and a bandaid that other hardware drivers won't implement.
On Thu, Oct 13, 2011 at 1:21 AM, Kumar Sanghvi kuma...@chelsio.com
On 10/13/2011 11:01 AM, Roland Dreier wrote:
Would this generate a completion event even if no completion entries are queued?
I guess it can if the QP has no WRs posted at all.
Maybe I'm misunderstanding, but this sounds like a bandaid for broken
applications,
and a bandaid that other
Hi,
1. I would like to submit user space library for a new RDMA adapter.
Can you please do needful for creating empty project under
http://git.openfabrics.org/git/projects/~ppandit/libocrdma.git?
2. For adding hardware driver for a new RDMA adapter, to which git tree(s) do I
need to submit
My latest patches are at:
git://git.openfabrics.org/~shefty/rdma-dev.git xrc
So I went through this and merged it to my tree (pretty much only conflicts
from 3.0-3.1-rc fixed, commit log changes and other minor cleanups).
The result is pushed out to my github for-next branch, with the
On Thu, 13 Oct 2011, Roland Dreier wrote:
My latest patches are at:
git://git.openfabrics.org/~shefty/rdma-dev.git xrc
So I went through this and merged it to my tree (pretty much only conflicts
from 3.0-3.1-rc fixed, commit log changes and other minor cleanups).
We got the XRC
Oh yeah and can we can FDR support in for-next as well?
--
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
On Thu, Oct 13, 2011 at 10:17 AM, Christoph Lameter c...@gentwo.org wrote:
There seems to be some stuff missing in the upstream code compared to the
OFED releases:
1. Raw ethernet support (IB_QPT_RAW_ETH) is missing.
2. MLX4_IB_QP_BLOCK_LOOPBACK is broken it seems? All packets are fed back
On Thu, 13 Oct 2011, Roland Dreier wrote:
On Thu, Oct 13, 2011 at 10:17 AM, Christoph Lameter c...@gentwo.org wrote:
There seems to be some stuff missing in the upstream code compared to the
OFED releases:
1. Raw ethernet support (IB_QPT_RAW_ETH) is missing.
2.
I tried posting to an openfabrics.org list first...
Date: Thu, 13 Oct 2011 09:51:57 -0700
From: general-boun...@lists.openfabrics.org
Subject: Auto-response for your message to the general mailing list
This list is no longer active. Please use linux-rdma@vger.kernel.org
instead. Thanks.
On Thu, Oct 13, 2011 at 10:24 AM, Christoph Lameter c...@gentwo.org wrote:
Clean reviewed patches for this are where?
They are in OFED-1.5.3.1 so they were already released.
OFED is neither clean nor reviewed. Really. The stuff in OFED always
needs a bunch
of review before it is suitable for
The result is pushed out to my github for-next branch, with the
expectation that I'll ask Linus to pull for 3.2.
Thanks - I'll take a look and test again.
However I do have one question: the last patch
(RDMA/uverbs: Export ib_open_qp() capability to user space in
my tree) adds
On Thu, 13 Oct 2011, Roland Dreier wrote:
On Thu, Oct 13, 2011 at 10:24 AM, Christoph Lameter c...@gentwo.org wrote:
Clean reviewed patches for this are where?
They are in OFED-1.5.3.1 so they were already released.
OFED is neither clean nor reviewed. Really. The stuff in OFED always
On Thu, Oct 13, 2011 at 9:40 AM, parav.pan...@emulex.com wrote:
2. For adding hardware driver for a new RDMA adapter, to which git tree(s) do
I need to submit patches?
openfabrics.org as well as kernel.org or just openfabrics is sufficient?
git://git.openfabrics.org/ofed_1_5/linux-2.6.git,
On Thu, Oct 13, 2011 at 10:31 AM, Hefty, Sean sean.he...@intel.com wrote:
ib_open_qp() is implemented entirely in the verbs layer (verbs.c). The OFED
API compatibility support that I added to libibverbs makes use of this call,
which I tested by running OSU's mvapich2.
Wait, now I'm baffled
Upon completion of a work request on the recieve queue the
IW_CXGB4 driver was incorrectly posting a completion back to
the recieve queue instead of the send queue. This resulted in
hanging worker threads because they were never notified that
the work requests were completed.
This change fixes
On Thu, Oct 13, 2011 at 11:15 AM, Jonathan Lallinger jonat...@ogc.us wrote:
Upon completion of a work request on the recieve queue the
IW_CXGB4 driver was incorrectly posting a completion back to
the recieve queue instead of the send queue
Wait, what?
On a receive completion you want to add a
Wait, now I'm baffled by the patch (ie
http://git.openfabrics.org/git?p=~shefty/rdma-
dev.git;a=commitdiff;h=1ec4e62a6e967ddc258e7c4e674168debb727d39)
I don't see anything that calls ib_uverbs_open_qp(). Am I missing something??
Does the OFED API compatibility actually call this function
On Thu, Oct 13, 2011 at 11:32 AM, Hefty, Sean sean.he...@intel.com wrote:
I'm confused now. The patch definitely looks like it's missing a change to
uverbs_main.c to setup the command table. (I thought you were referring to
needing a change to struct ib_device before.)
Right, we need to
When creating flushed recv CQEs, set the QPID field in
the t4_cqe to the SQ QID and not the RQ QID. Otherwise
the poll code will not find the correct qp context.
Signed-off by: Jonathan Lallinger jonat...@ogc.us
Signed-off by: Steve Wise sw...@ogc.us
---
drivers/infiniband/hw/cxgb4/cq.c |2
From: Randy Dunlap rdun...@xenotime.net
Fix printk format warning seen on x86_64:
drivers/infiniband/hw/nes/nes_cm.c:3190:2: warning: format '%zu' expects type
'size_t', but argument 11 has type 'int'
Signed-off-by: Randy Dunlap rdun...@xenotime.net
Cc: Faisal Latif faisal.la...@intel.com
---
This supports the common options for CA, Port, and timeout.
Signed-off-by: Ira Weiny wei...@llnl.gov
---
Makefile.am |1 +
configure.in |1 +
etc/ibdiag.conf | 13 +++
man/infiniband-diags.8| 198 ---
We need to add an entry into the uverbs and device command
tables to allow user space to actually call ib_open_qp.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
If possible, this should just be merged with the last patch in the XRC
series.
In my previous tests, this was not getting called.
25 matches
Mail list logo
