Hefty, Sean sean.he...@... writes:
I added a while(1) loop to rdma_server to allow clients to connected
repeatedly, and this worked for me. Jonathan, can you see if this
works for your testing as well? If so, I'll commit.
Yesterday I tried setting attr-send/recv_cq = NULL in
Works for me.
-Original Message-
From: linux-rdma-ow...@vger.kernel.org
[mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Hefty, Sean
Sent: Monday, October 18, 2010 6:25 PM
To: linux-rdma@vger.kernel.org; Sasha Khapyorsky
Subject: ib mad definitions
This has probably been discussed
On Tue, Oct 12, 2010 at 03:33:46PM -0500, Tom Tucker wrote:
Hi Bruce,
These fixes are ready for 2.6.37. They fix two bugs in the server-side
NFSRDMA transport.
Both applied and pushed out, thanks.
--b.
Thanks,
Tom
---
Tom Tucker (2):
svcrdma: Cleanup DMA unmapping in error
On Mon, Oct 18, 2010 at 6:24 PM, Hefty, Sean sean.he...@intel.com wrote:
This has probably been discussed before,
Yes, several times AFAIR.
but is there a strong reason why ib_types.h can't be moved from
opensm/include/iba to libibumad/include/infiniband?
Why does this need to be moved ?
* ib_wq is added, which is used as the common workqueue for infiniband
instead of the system workqueue. All system workqueue usages
including flush_scheduled_work() callers are converted to use and
flush ib_wq.
* cancel_delayed_work() + flush_scheduled_work() converted to
but is there a strong reason why ib_types.h can't be moved from
opensm/include/iba to libibumad/include/infiniband?
Why does this need to be moved ?
The dependency should be on libibumad, not opensm. libibumad is pretty much
useless without these definitions. Why wouldn't you move them?
Randy,
...back from vacation.
Many thanks! I'll take it all over.
Bernard.
Randy Dunlap randy.dun...@oracle.com wrote on 10/15/2010 12:57:03 AM:
snip
+
+User Interface
+--
+All fast path operations such as posting of work requests and
+reaping of work completions
On Tue, Oct 19, 2010 at 11:28 AM, Hefty, Sean sean.he...@intel.com wrote:
but is there a strong reason why ib_types.h can't be moved from
opensm/include/iba to libibumad/include/infiniband?
Why does this need to be moved ?
The dependency should be on libibumad, not opensm. libibumad is
I agree ib_types.h is more generic than opensm. Moving to libibmad and
making opensm depend on this is probably better than all the
duplication. There have been viewpoints that libibumad and libibmad
shouldn't be separate (as they are small) but they were never combined
into a single library.
On Tue, Oct 19, 2010 at 12:48 PM, Hefty, Sean sean.he...@intel.com wrote:
I agree ib_types.h is more generic than opensm. Moving to libibmad and
making opensm depend on this is probably better than all the
duplication. There have been viewpoints that libibumad and libibmad
shouldn't be
On Tue, 2010-10-19 at 08:24 -0700, Tejun Heo wrote:
* qib_cq_wq is a separate singlethread workqueue. Does the queue
require strict single thread execution ordering? IOW, does each
work have to be executed in the exact queued order and no two works
should execute in parallel? Or was
On Tue, 19 Oct 2010 08:43:22 -0700
Hal Rosenstock hal.rosenst...@gmail.com wrote:
On Tue, Oct 19, 2010 at 11:28 AM, Hefty, Sean sean.he...@intel.com wrote:
but is there a strong reason why ib_types.h can't be moved from
opensm/include/iba to libibumad/include/infiniband?
Why does this
On Tue, Oct 19, 2010 at 5:24 PM, Tejun Heo t...@kernel.org wrote:
[ ... ]
This is to prepare for deprecation of flush_scheduled_work().
[ ... ]
Index: work/include/rdma/ib_verbs.h
[ ... ]
+extern struct workqueue_struct *ib_wq;
[ ... ]
This patch adds a declaration of a global variable to
ib_types depends on complib at the moment (fixable)
ibutils depends on OpenSM (it will anyway -- non-issue)
somethings in ib_types are ugly, byteswapping (non-issue; deal with it
later)
OpenSM may _not_ include umad and therefore miss defines. (fixable?)
As for this last item, would it be
On Tue, 19 Oct 2010 11:50:46 -0700
Hefty, Sean sean.he...@intel.com wrote:
ib_types depends on complib at the moment (fixable)
ibutils depends on OpenSM (it will anyway -- non-issue)
somethings in ib_types are ugly, byteswapping (non-issue; deal with it
later)
OpenSM may _not_ include
Thanks! Applied
-Original Message-
From: Pradeep Satyanarayana [mailto:prade...@linux.vnet.ibm.com]
Sent: Monday, October 18, 2010 1:23 PM
To: Davis, Arlin R
Cc: linux-rdma
Subject: [PATCH] Hang in dat_ia_open()
Hi Arlin,
During some error case testing we discovered a hang in
On Tue, Oct 19, 2010 at 11:50:46AM -0700, Hefty, Sean wrote:
We start with a minimal set of definitions to umad and add/move
other definitions later as needed, creating new header files where
appropriate (umad_smi.h, umad_pm.h, etc.)
If we can get some basic agreement on this, I'll start on
Just want to let you all know that OpenSM seems to work fine with Centos5.5 on
the same HW.
Thanks,
Suri
-Original Message-
From: linux-rdma-ow...@vger.kernel.org
[mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Suresh
Shelvapille
Sent: Wednesday, October 13, 2010 3:07 PM
Ira Weiny wrote:
On Tue, 19 Oct 2010 11:50:46 -0700
Hefty, Sean sean.he...@intel.com wrote:
ib_types depends on complib at the moment (fixable)
ibutils depends on OpenSM (it will anyway -- non-issue)
somethings in ib_types are ugly, byteswapping (non-issue; deal with
it later) OpenSM may
Just to be painfully clear ...
A user-mode application would then only need to include ib_types.h + CM
flavor of choice .h files ?
For compatibility, ib_types.h would include whatever files any definitions were
moved to. An application that includes ib_types.h today wouldn't need
additional
Can we at least agree on the usage of these structures first? Are the
constants going to be in host or network byte order?
I was simply suggesting to 'move' some of the existing structures and defines.
Are you going to make something like the kernel where there is a
native structure and
On Tue, Oct 19, 2010 at 06:00:51PM -0700, Hefty, Sean wrote:
Can we at least agree on the usage of these structures first? Are the
constants going to be in host or network byte order?
I was simply suggesting to 'move' some of the existing structures and defines.
But they are horrible and
On Tue, 19 Oct 2010 18:00:51 -0700
Hefty, Sean sean.he...@intel.com wrote:
Can we at least agree on the usage of these structures first? Are the
constants going to be in host or network byte order?
I was simply suggesting to 'move' some of the existing structures and defines.
Are you
On Tue, 19 Oct 2010 18:09:58 -0700
Jason Gunthorpe jguntho...@obsidianresearch.com wrote:
On Tue, Oct 19, 2010 at 06:00:51PM -0700, Hefty, Sean wrote:
Can we at least agree on the usage of these structures first? Are the
constants going to be in host or network byte order?
I was
On Tue, Oct 19, 2010 at 06:32:57PM -0700, Ira Weiny wrote:
On Tue, 19 Oct 2010 18:09:58 -0700
Jason Gunthorpe jguntho...@obsidianresearch.com wrote:
On Tue, Oct 19, 2010 at 06:00:51PM -0700, Hefty, Sean wrote:
Can we at least agree on the usage of these structures first? Are the
On Tue, Oct 19, 2010 at 06:12:56PM -0700, Ira Weiny wrote:
I am all for cleaner, more capable... but why incompatible? If we want to
start fresh and then convert OpenSM later, fine. But _don't_ forget to go
back and convert OpenSM, because if you leave ib_types.h out there someone is
going
26 matches
Mail list logo
