On 4/24/2014 2:30 AM, Devesh Sharma wrote:
Hi Chuck
Following is the complete call trace of a typical NFS-RDMA transaction while
mounting a share.
It is unavoidable to stop calling post-send in case it is not created.
Therefore, applying checks to the connection state is a must
While
On 23/04/2014 16:44, Hefty, Sean wrote:
Regarding SubnetTimeout changes: the code in
drivers/infiniband/core/cache.c already queues a work request after each
port state change. Inside that work request e.g. the P_Key cache is
updated. Would it be acceptable to modify ib_cache_update() such that
Hi Hugh,
Sorry for late reply. First of all, to avoid the confusion, I think the
patch is fine.
When I saw this patch I decided that uprobes should be updated accordingly,
but I just realized that I do not understand what should I write in the
changelog.
On 04/04, Hugh Dickins wrote:
+
On 02/03/2014 12:49, Haggai Eran wrote:
The following set of patches implements on-demand paging (ODP) support
in the RDMA stack and in the mlx5_ib Infiniband driver.
I've placed the latest cut of the ODP patches on my public git tree @
git://beany.openfabrics.org/~ogerlitz/linux-2.6.git odp
On Apr 24, 2014, at 3:12 AM, Sagi Grimberg sa...@dev.mellanox.co.il wrote:
On 4/24/2014 2:30 AM, Devesh Sharma wrote:
Hi Chuck
Following is the complete call trace of a typical NFS-RDMA transaction while
mounting a share.
It is unavoidable to stop calling post-send in case it is not
Thanks Chuck for summarizing.
One more issue is being added to the list below.
-Original Message-
From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
ow...@vger.kernel.org] On Behalf Of Chuck Lever
Sent: Thursday, April 24, 2014 8:31 PM
To: Sagi Grimberg
Cc: Devesh Sharma;
In cases where the cm calls c4iw_modify_rc_qp() with the endpoint
mutex held, they must be called with internal == 1. rx_data() and
process_mpa_reply() are not doing this. This causes a deadlock because
c4iw_modify_rc_qp() might call c4iw_ep_disconnect() in some !internal
cases, and
This is required to work around a T5 HW issue.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/cm.c |8
drivers/infiniband/hw/cxgb4/t4fw_ri_api.h | 14 ++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git
The whole db drop avoidance stuff is for T4 only. So we cannot allow
that to be enabled for T5 devices.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/qp.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git
In cases where the cm calls c4iw_modify_rc_qp() with the endpoint
mutex held, they must be called with internal == 1. rx_data() and
process_mpa_reply() are not doing this. This causes a deadlock because
c4iw_modify_rc_qp() might call c4iw_ep_disconnect() in some !internal
cases, and
This is required to work around a T5 HW issue.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/cm.c |8
drivers/infiniband/hw/cxgb4/t4fw_ri_api.h | 14 ++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git
The whole db drop avoidance stuff is for T4 only. So we cannot allow
that to be enabled for T5 devices.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/qp.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git
On Thu, 24 Apr 2014, Oleg Nesterov wrote:
Hi Hugh,
Sorry for late reply. First of all, to avoid the confusion, I think the
patch is fine.
When I saw this patch I decided that uprobes should be updated accordingly,
but I just realized that I do not understand what should I write in the
Sean, can't we have CMA to follow the same practice used in the CM where
we derive the RC QP timeout based on the packet life time retrieved in
path queries? e.g base the cm response time out on this value too?
We could. The timeout that's being modified by the patch is the time needed by
On Thu, Apr 24, 2014 at 12:54:40PM +0300, sagi grimberg wrote:
Well, I feel the same way (although less harsh about it), I would
prefer to have it all inbox.
As I see it, OFED is useful for costumers who want to upgrade RDMA
functionality (or get Tech previews)
without upgrading their distro
Claim your 500,000,00 Euros
--
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, Apr 24, 2014 at 10:38:25PM -0700, Christoph Hellwig wrote:
On Thu, Apr 24, 2014 at 12:54:40PM +0300, sagi grimberg wrote:
Well, I feel the same way (although less harsh about it), I would
prefer to have it all inbox.
As I see it, OFED is useful for costumers who want to upgrade RDMA
17 matches
Mail list logo
