Liran Liss wrote:
but keeping ib_create_ah() callable from any context is not a goal by itself.
going with your approach, if your proposed design is accepted, I believe that
you probably need to patch all the code-chains that makes calls under the
current assumption
I am looking for
On 7/7/2010 8:42 AM, Or Gerlitz wrote:
Jack, Tziporet
Can you clarify the status of the upstream kernel mlx4 multi-protocol
support? looking on Linus git, I see one commit,
7ff93f8b7ecbc36e7ffc5c11a61643821c1bfee5 mlx4_core: Multiple port type
support dated to Oct 2008, wheres ofed
Tziporet Koren wrote:
Jack is on vacation and will be back in 2 weeks. I will ask him to look at this
when he is back
All this could have been much simpler if Yevgeny was responding, he's
signed on the multi-protocol related patches shipped with ofed. So far,
I had hard time getting responses
On 10:00 Tue 06 Jul , Roland Dreier wrote:
Seems that anyone who cared could already easily write a tiny shim in C
and then write the rest of their plugin in C++. Or are there deeper
issues than names of methods?
I think that it is likely deeper. For instance if C++ stuff will use
Roland Dreier rdre...@cisco.com wrote:
thanks, applied
I don't see it, and none of the other patches you accepted last night,
in the for-next brach of yours, where are they...?
Or.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to
I don't see it, and none of the other patches you accepted last night,
in the for-next brach of yours, where are they...?
Sitting on my local system ;)
Forgot to do git push to kernel.org.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
Steve,
merging the port space of different transports is very particular
and it would be good if we could avoid it w/o losing on transport
independence. Could we prove a strong need for that short-cut?
If its really needed, one global RDMA_CM instance should be able
to achive that requirement.
Bernard Metzler wrote:
Steve,
merging the port space of different transports is very particular
and it would be good if we could avoid it w/o losing on transport
independence.
But the IB and IW port space is _already_ merged by the RDMA_CM. That's
my point. So a solution that breaks this
Or,
What needs to be done such that the dapl debug prints be seen
either in the system log or the standard output/error of the mpi rank?
There is limited debug in the non-debug builds. If you
want full debugging capabilities you can install the
source RPM and configure and make as follow
Hi Jim,
On 13:53 Tue 15 Jun , Jim Schutt wrote:
diff --git a/opensm/opensm/osm_opensm.c b/opensm/opensm/osm_opensm.c
index d3dc02e..5614240 100644
--- a/opensm/opensm/osm_opensm.c
+++ b/opensm/opensm/osm_opensm.c
@@ -147,7 +147,8 @@ static void append_routing_engine(osm_opensm_t *osm,
Hi Sasha:
On Wed, 2010-07-07 at 11:06 -0600, Sasha Khapyorsky wrote:
Hi Jim,
On 13:53 Tue 15 Jun , Jim Schutt wrote:
diff --git a/opensm/opensm/osm_opensm.c b/opensm/opensm/osm_opensm.c
index d3dc02e..5614240 100644
--- a/opensm/opensm/osm_opensm.c
+++ b/opensm/opensm/osm_opensm.c
But the IB and IW port space is _already_ merged by the RDMA_CM. That's
my point. So a solution that breaks this impacts transport-independent
applications that use the rdma cm...
Could we prove a strong need for that short-cut?
If its really needed, one global RDMA_CM instance should
Tung, Chien Tin wrote:
But the IB and IW port space is _already_ merged by the RDMA_CM. That's
my point. So a solution that breaks this impacts transport-independent
applications that use the rdma cm...
Could we prove a strong need for that short-cut?
If its really needed, one global
From: Steven Dake sd...@cast.broked.org
The readdir POSIX api is not thread safe. This presents problems in
multithreaded programs that use the libibverbs APIs. This patch has been
tested with a libibverbs application (http://www.corosync.org) on
Mellanox MT26428 cards.
Signed-off-by: Steven
On Wed, Jul 07, 2010 at 11:37:01AM -0700, Steven Dake wrote:
From: Steven Dake sd...@cast.broked.org
The readdir POSIX api is not thread safe. This presents problems in
multithreaded programs that use the libibverbs APIs. This patch has been
tested with a libibverbs application
The readdir POSIX api is not thread safe. This presents problems in
multithreaded programs that use the libibverbs APIs. This patch has been
tested with a libibverbs application (http://www.corosync.org) on
Mellanox MT26428 cards.
This is a bit vague. Is the problem that other threads
On 07/07/2010 11:52 AM, Jason Gunthorpe wrote:
On Wed, Jul 07, 2010 at 11:37:01AM -0700, Steven Dake wrote:
From: Steven Dakesd...@cast.broked.org
The readdir POSIX api is not thread safe. This presents problems in
multithreaded programs that use the libibverbs APIs. This patch has been
On 07/07/2010 11:54 AM, Roland Dreier wrote:
The readdir POSIX api is not thread safe. This presents problems in
multithreaded programs that use the libibverbs APIs. This patch has been
tested with a libibverbs application (http://www.corosync.org) on
Mellanox MT26428 cards.
On Wed, Jul 07, 2010 at 12:14:16PM -0700, Steven Dake wrote:
But, you surely could not have seen a bug on Linux that was caused by
this - so why was this patch prepared?
We redefine all the non-thread-safe posix calls in our package (such as
readdir) to assert(0). This prevents their
On 07/07/2010 01:47 PM, Jason Gunthorpe wrote:
On Wed, Jul 07, 2010 at 12:14:16PM -0700, Steven Dake wrote:
But, you surely could not have seen a bug on Linux that was caused by
this - so why was this patch prepared?
We redefine all the non-thread-safe posix calls in our package (such as
On 11:57 Wed 07 Jul , Jim Schutt wrote:
So I think the end of the above chunk only needs to be
-
- str = strdup(engine_names);
- name = strtok_r(str, , \t\n, p);
- while (name *name) {
- setup_routing_engine(osm, name);
- name = strtok_r(NULL,
On Wed, Jul 07, 2010 at 02:24:45PM -0700, Steven Dake wrote:
Not sure how to map a readdir to readdir_r on a thread unsafe system...
perhaps with thread keys. In any regard, seems pointless, readdir_r is
there and what POSIX specifies for this purpose.
Override opendir and allocate the
From: Steven Dake sd...@cast.broked.org
The readdir POSIX api is not thread safe. This presents problems in
multithreaded programs that use the libibverbs APIs. This patch has been
tested with a libibverbs application (http://www.corosync.org) on
Mellanox MT26428 cards.
This updated version
On 07/07/2010 02:49 PM, Jason Gunthorpe wrote:
On Wed, Jul 07, 2010 at 02:24:45PM -0700, Steven Dake wrote:
Not sure how to map a readdir to readdir_r on a thread unsafe system...
perhaps with thread keys. In any regard, seems pointless, readdir_r is
there and what POSIX specifies for this
From: Ira Weiny wei...@llnl.gov
Date: Wed, 7 Jul 2010 17:35:34 -0700
Subject: [PATCH] ib_qib: Allow writes to the diag_counters to be able to clear
them
Signed-off-by: Ira Weiny wei...@llnl.gov
---
drivers/infiniband/hw/qib/qib_sysfs.c | 16 +++-
1 files changed, 15
25 matches
Mail list logo
