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
> g
On Tue, Oct 19, 2010 at 06:32:57PM -0700, Ira Weiny wrote:
> On Tue, 19 Oct 2010 18:09:58 -0700
> Jason Gunthorpe 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 i
On Tue, 19 Oct 2010 18:09:58 -0700
Jason Gunthorpe 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 simply suggesting to 'move
On Tue, 19 Oct 2010 18:00:51 -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.
>
> > Are you going to ma
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
> 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 p
> 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
addition
Ira Weiny wrote:
> On Tue, 19 Oct 2010 11:50:46 -0700
> "Hefty, Sean" 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_
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
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
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 d
On Tue, 19 Oct 2010 11:50:46 -0700
"Hefty, Sean" 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 umad and t
> 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
On Tue, Oct 19, 2010 at 5:24 PM, Tejun Heo 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 a public
On Tue, 19 Oct 2010 08:43:22 -0700
Hal Rosenstock wrote:
> On Tue, Oct 19, 2010 at 11:28 AM, Hefty, Sean 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 d
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 w
On Tue, Oct 19, 2010 at 12:48 PM, Hefty, Sean 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 separate (as they ar
> 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 libr
On Tue, Oct 19, 2010 at 11:28 AM, Hefty, Sean 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 pretty much
Randy,
...back from vacation.
Many thanks! I'll take it all over.
Bernard.
Randy Dunlap wrote on 10/15/2010 12:57:03 AM:
> > +
> > +User Interface
> > +--
> > +All fast path operations such as posting of work requests and
> > +reaping of work completions currently involve a syst
> > 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 th
* 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
cancel_delayed_w
On Mon, Oct 18, 2010 at 6:24 PM, Hefty, Sean 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 ?
> This appears to b
What is the best way to time RDMA over IB code segments? Are there
timers included in the RDMA libs?
Ed
--
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
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
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
Hefty, Sean 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 rdma_get_request() which
27 matches
Mail list logo
