On Mon, Jan 10, 2011 at 10:51:13AM -0800, Roland Dreier wrote:
> Maybe we can use MST's current email to ask him... Michael, do you have
> any memory of the issue we worked around here?
>
> > I have question regarding workaround introduced in commit 559ce8f1 of
> > the mainline tree:
> >
> >
Sean, the following commit
commit bf2944bd56c7a48cc3962a860dbc4ceee6b1ace8
Author: Sean Hefty <[EMAIL PROTECTED]>
Date: Tue Jun 5 09:57:31 2007 -0700
RDMA/cma: Fix initialization of next_port
next_port should be between sysctl_local_port_range[0] and [1]
Hi!
I noticed that RHEL backports include a copy of include/scsi/iscsi_proto.h from
upstream kernel which is a large file, so carrying it around is a maintainance
problem going forward. Since this header includes protocol definitions, I think
we should check it out from upstream, always.
Code for
> Quoting Erez Zilber <[EMAIL PROTECTED]>:
> Subject: Re: suggested fix in iscsi RHEL backport
>
> Michael S. Tsirkin wrote:
>
> > Hi!
> > I noticed that RHEL backports include a copy of include/scsi/iscsi_proto.h
> > from
> > upstream kernel whic
.
--
Michael S. Tsirkin - Staff Engineer, Mellanox Technologies Ltd.
Eternity is a very long time, especially towards the end.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
For whom it may concern,
I have created an ofed git tree updated with kernel bits from 2.6.22-rc4,
and put that up at git://git.openfabrics.org/~mst/ofed_kernel.git
It may be useful to anyone interested in testing 2.6.22-rc4 technology
(such as mlx4) on older kernels, testing SDP with 2.6.22-rc4 b
Tziporet, I pushed a fix to a critical bug:
https://bugs.openfabrics.org/show_bug.cgi?id=658
Can you approve it pls?
Vlad, if approved, please pull.
--
MST
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/list
l ask Tziporet to approve, too.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
diff --git a/kernel_patches/fixes/iscsi_scsi_makefile.patch
b/kernel_patches/fixes/iscsi_scsi_makefile.patch
deleted file mode 100644
index 9c4fd01..000
--- a/kernel_patches/fixes/iscsi_scsi_makefi
FYI,
git://git.openfabrics.org/~mst/ofed_kernel.git
I've merged in 2.6.22-rc5 which will pull in multiple bug fixes.
I also added local sa patch back in (not sure how
but it went missing).
--
Michael S. Tsirkin - Staff Engineer, Mellanox Technologies Ltd.
Eternity is a very long
Fix a crasher bug in IPoIB CM: once QP is in RTR, an RX completion (and even an
asynchronous error) might be observed on this QP, so we have to initialize all
RX fields beforehand.
This fixes bug <https://bugs.openfabrics.org/show_bug.cgi?id=662>
Signed-off-by: Michael S. Tsirkin &
passive_ids list is also
left in place to reduce the chance of the RX being mis-detected as stale.
This fixes bug <https://bugs.openfabrics.org/show_bug.cgi?id=662>
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
---
Resending - Roland, is the changelog OK?
Please consider this bugfi
> Quoting Jeremy Brown <[EMAIL PROTECTED]>:
> Subject: Re: Issue with IPoIB-CM being enabled at boot
>
> I apologize for replying to myself, but I just set up two em64t systems
> with Mellanox HCAs, Fedora 4, and a fresh build and installation of OFED
> 1.2, and the IPoIB interfaces came up in dat
> Quoting Jeremy Brown <[EMAIL PROTECTED]>:
> Subject: Re: Issue with IPoIB-CM being enabled at boot
>
> On Tue, 2007-07-03 at 14:01 +0300, Michael S. Tsirkin wrote:
> > > Quoting Jeremy Brown <[EMAIL PROTECTED]>:
> > > Subject: Re: Issue with IPo
> Quoting Hal Rosenstock <[EMAIL PROTECTED]>:
> Subject: Re: Re: Bug 667
>
> Vlad,
>
> On Thu, 2007-07-05 at 14:47, Vladimir Sokolovsky wrote:
> > Sean Hefty wrote:
> > >> Please push the following commit to your ofed_1_2 branch to be
> > >> included in the OFED-1.2.1:
> > >
> > > Let me know w
> Let me give an example. In OFED 1.0, you shipped dapl version 1.2. In
> OFED 1.1, you also shipped dapl version 1.2. However, code inspection
> shows that between OFED 1.0 and OFED 1.1, dapl did in fact change (not a
> lot, but anything is enough). So, between OFED 1.0 and OFED 1.1, you
> hav
> Quoting Doug Ledford <[EMAIL PROTECTED]>:
> Subject: Re: RFC OFED-1.3 installation
>
> On Tue, 2007-07-17 at 18:25 +0300, Michael S. Tsirkin wrote:
> > > Let me give an example. In OFED 1.0, you shipped dapl version 1.2. In
> > > OFED 1.1, you also ship
> Quoting Doug Ledford <[EMAIL PROTECTED]>:
> Subject: Re: RFC OFED-1.3 installation
>
> On Tue, 2007-07-17 at 19:27 +0300, Michael S. Tsirkin wrote:
> > > Quoting Doug Ledford <[EMAIL PROTECTED]>:
> > > Subject: Re: RFC OFED-1.3 installation
>
> Quoting Doug Ledford <[EMAIL PROTECTED]>:
> Subject: Re: RFC OFED-1.3 installation
>
> On Tue, 2007-07-17 at 19:45 +0300, Michael S. Tsirkin wrote:
> > > Quoting Doug Ledford <[EMAIL PROTECTED]>:
> > > Subject: Re: RFC OFED-1.3 installation
>
> There are lots of things that we as a distributor have to care about
> that upstream generally does not. The spec file and patches are how we
> solve our customer's problems. They are what make a stable
> distribution, as opposed to a "bleeding edge, must always update to
> latest upstream vers
> So you need to be able to
> tell the difference between a customer running libibverbs-1.0.4 from
> OFED-1.3-beta1 and libibverbs-1.0.4 from OFED-1.3 final.
I don't really think we want customers to run beta code, or intend to support
such configurations.
--
MST
___
> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] Re: RFC OFED-1.3 installation
>
> > I don't really think we want customers to run beta code
>
> What's the point of a beta then??
Donnu.
In previous OFED releases, we had "release candidates" rather than "beta".
Openfabri
> Quoting Scott Weitzenkamp (sweitzen) <[EMAIL PROTECTED]>:
> Subject: RE: [ofa-general] Re: RFC OFED-1.3 installation
>
> > > So you need to be able to
> > > tell the difference between a customer running libibverbs-1.0.4 from
> > > OFED-1.3-beta1 and libibverbs-1.0.4 from OFED-1.3 final.
> >
>
> Quoting Scott Weitzenkamp (sweitzen) <[EMAIL PROTECTED]>:
> Subject: RE: [ofa-general] Re: RFC OFED-1.3 installation
>
>
> > > > I don't really think we want customers to run beta code
> > >
> > > What's the point of a beta then??
> >
> > Donnu.
> > In previous OFED releases, we had "release
> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] Re: RFC OFED-1.3 installation
>
> > But daily ... we don't want to increment a revision on each change, do we?
>
> I think it's easy enough to make the revision of the RPMS be something
> like -0.1.2007-07-17.1 or somethin
> Quoting Doug Ledford <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] Re: RFC OFED-1.3 installation
>
> On Wed, 2007-07-18 at 00:09 +0300, Michael S. Tsirkin wrote:
> > > Quoting Roland Dreier <[EMAIL PROTECTED]>:
> > > Subject: Re: [ofa-general] Re: R
> Quoting Doug Ledford <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] Re: RFC OFED-1.3 installation
>
> On Wed, 2007-07-18 at 05:18 +0300, Michael S. Tsirkin wrote:
> > > Quoting Doug Ledford <[EMAIL PROTECTED]>:
> > > Subject: Re: [ofa-general] Re:
>Quoting Arthur Jones <[EMAIL PROTECTED]>:
>Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
>hi michael, ...
>
>On Tue, Jun 12, 2007 at 11:41:08AM +0300, Michael S. Tsirkin wrote:
>> For whom it may concern,
>> I have created an of
> Quoting Arthur Jones <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> hi michael, ...
>
> On Tue, Jul 24, 2007 at 06:03:41AM +0300, Michael S. Tsirkin wrote:
> > [...]
> > But I also see a serious proble
> Quoting Arthur Jones <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> hi michael, ...
>
> On Tue, Jul 24, 2007 at 06:32:28PM +0300, Michael S. Tsirkin wrote:
> > [...]
> > > > For example, gi
> Quoting Arthur Jones <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> hi michael, ...
>
> On Tue, Jul 24, 2007 at 06:09:09PM +0300, Michael S. Tsirkin wrote:
> > > Quoting Arthur Jones <[EMAIL PROTECTE
> Quoting Sean Hefty <[EMAIL PROTECTED]>:
> Subject: RE: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> >at qlogic we now keep the backports as branches in
> >our git tree and this, i find, is much easier to
> >handle. because:
> >
> >* viewing and navigating backport source bec
> Quoting Arthur Jones <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> hi michael, ...
>
> On Tue, Jul 24, 2007 at 06:53:48PM +0300, Michael S. Tsirkin wrote:
> > [...]
> > > well, no, i _have_ be
> > Because you only have your driver to maintain.
>
> no, i have to maintain quite a few of the
> ofed backport branches as well for our release.
> if i started getting pull requests from people
> with changes to 15 backport branches in one go,
> i'd probably want to script it...
Yea. Happens al
> Quoting Arthur Jones <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> hi michael, ...
>
> On Tue, Jul 24, 2007 at 07:16:46PM +0300, Michael S. Tsirkin wrote:
> > [...]
> > But, for these cases where th
> one of the goals of OFED 1.3 is to make access
> to the source easier. to do that, we will prob
> need to rid ourselves of patches...
I'm working on a rather simpler solution to this problem.
Stay tuned.
--
MST
___
ewg mailing list
ewg@lists.openfab
> i realize that you're attached to your current method,
> but i've _used_ a different method, and i can say from
> experience that it works _much_ better...
I'd like to see a clean method, that doesn't replace one set of
problems that I understand with another that I have to learn.
> at sonoma,
> Quoting Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> >Hmm. Concider that yuou did all of the above, and then mail me
> >that there's an update. Now I need to merge updates to multiple branches
> >directly
> >and git pull does no
> Quoting Sean Hefty <[EMAIL PROTECTED]>:
> Subject: RE: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> >Examples: What if there's a conflict? I currently do git reset, we'll
>
> If there's a conflict applying a patch, you reject it. I fail to see any
> issue
> here.
But the
> i'd _really_ like to see a list of the advantages of
> patches over branches. it's hard for me to know if
> i'm just missing something if the case is not laid out...
Here's a short list off the top of my head
- A single git pull merges any number of backport changes
- A single git reset ORIG_H
> Quoting Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> >But the proposal here was to have a bush of branches, all of which
> >need to be merged at the same time. It's possible that some
> >would merge and some would fail, leaving m
> Quoting Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> >Here's a short list off the top of my head
> >
> >- A single git pull merges any number of backport changes
> >- A single git reset ORIG_HEAD recovers from a conflicting merge
> > - A single git reset ORIG_HEAD recovers from a conflicting merge
>
> handling conflicts is a big part of a maintainer's job!
Because you are a driver maintainer.
That's what's different here from regular merge.
Please understand: we have upstream code and we have changes against it.
Upstream
> Quoting Stefan Roscher <[EMAIL PROTECTED]>:
> Subject: [PATCH ofed-1.2-rc3 2/4] ehca: backport for rhel-4.5 - mmap
> functonality
>
>
>
> Signed-off-by: Stefan Roscher <[EMAIL PROTECTED]>
> ---
> backport_ehca_2_rhel45_umap.patch | 850
> ++
> 1 files chan
Erez, add_open_iscsi_h currently does:
-#include
+#include "iscsi_if.h"
why is ths bit needed?
--
MST
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
> Quoting Erez Zilber <[EMAIL PROTECTED]>:
> Subject: Re: add_open_iscsi_h.patch
>
> Michael S. Tsirkin wrote:
>
> > Erez, add_open_iscsi_h currently does:
> >
> > -#include
> > +#include "iscsi_if.h"
> >
> > why is ths bit
> Quoting Erez Zilber <[EMAIL PROTECTED]>:
> Subject: Re: add_open_iscsi_h.patch
>
> Michael S. Tsirkin wrote:
>
> > Erez, add_open_iscsi_h currently does:
> >
> > -#include
> > +#include "iscsi_if.h"
> >
> > why is ths bit
> Quoting Erez Zilber <[EMAIL PROTECTED]>:
> Subject: Re: add_open_iscsi_h.patch
>
> Michael S. Tsirkin wrote:
>
> > > Quoting Erez Zilber <[EMAIL PROTECTED]>:
> > > Subject: Re: add_open_iscsi_h.patch
> > >
> > > Michael S. Tsi
Hi!
I'd like to announce a couple of updates that were recently made
to the build scripts on the ofed_kernel branch.
This is an attempt to answer repeated requests, aired at Sonoma,
to simplify access to kernel sources.
The idea is that a user of a supported kernel will just be able
to download an
> Quoting Erez Zilber <[EMAIL PROTECTED]>:
> Subject: Re: add_open_iscsi_h.patch
>
> Michael S. Tsirkin wrote:
>
> > > Quoting Erez Zilber <[EMAIL PROTECTED]>:
> > > Subject: Re: add_open_iscsi_h.patch
> > >
> > > Michael S. Tsirk
> > > also, if the upstream
> > > changes touch code that conflicts with a backport
> > > patch, you get to fix the problem as it happens
> >
> > That's exactly the thing that I do not want to do.
>
> you don't want to know about a problem a patch
> until days or weeks later when the auto build
>
> Quoting Hoang-Nam Nguyen <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH ofed-1.2-rc3 2/4] ehca: backport for rhel-4.5 - mmap
> functonality
>
> Hi Michael,
> Below is the version without conflicts. And it should compile.
Seems to apply fine. I pushed it out. Vlad, can you take it pls?
> As soon a
object
as a value.
Please comment.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
---
diff --git a/include/infiniband/verbs.h b/include/infiniband/verbs.h
index acc1b82..503f201 100644
--- a/include/infiniband/verbs.h
+++ b/include/infiniband/verbs.h
@@ -370,6 +370,11 @@ struct ibv_a
> Quoting Erez Zilber <[EMAIL PROTECTED]>:
> Subject: Why isn't kfifo get built with ib-core for RH4?
>
> Michael,
>
>
> I saw that kfifo that was built with ib-core for RH4 was removed:
>
>
> http://www2.openfabrics.org/git/?p=~vlad/ofed_kernel.git;a=commit;h=afe4186a2b383e58d9937d0b2fe2ddfb0
> On Sun, Jul 29, 2007 at 05:04:31PM +0300, Michael S. Tsirkin wrote:
> > Hello!
> > Here is an API proposal for support of the SRC
> > (scalable reliable connected) protocol extension in libibverbs.
> >
> > This adds APIs to:
> > - manage SRC domai
Some code examples:
/* create a domain and share it: */
struct ibv_src_domain * d = ibv_get_new_src_domain(ctx);
int fd = open(path, O_CREAT | O_RDWR, mode);
ibv_share_src_domain(d, fd);
/* get a reference to a shared domain: */
int fd = open(path,
More code examples:
Create an SRC QP, part of SRC domain:
attr.qp_type = IBV_QPT_SRC;
attr.src_domain = d;
qp = ibv_create_qp(pd, &attr);
Given remote SRQ number, send data to this SRQ over an SRC QP:
wr.src_remote_srq_num = src_remote_srq_num;
ib_post_se
> Quoting Gleb Natapov <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] RFC: SRC API
>
> On Mon, Jul 30, 2007 at 12:16:39PM +0300, Michael S. Tsirkin wrote:
> > More code examples:
> >
> > Create an SRC QP, part of SRC domain:
> >
> > attr.qp
> > It seems what you are missing is what SRC is, not how to use the API.
>
> So tell us.
This calls for a separate document. From feedback from Sonoma I really assumed
people have it figured out.
Let's open a separate thread, and there I will try writing up
what SRC is from the protocol point o
Here's some background on what SRC is. This is basically slide 6 in Dror's
talk, for those that missed the talk.
* * *
SRC is an extension supported by recent Mellanox hardware
which is geared toward reducing the number of QPs
required for all-to-all communication on systems
with a high number
> The following patches add kfifo to ibcore (for SLES9 & RH4). kfifo is taken
> from upstream code.
Thanks, applied to 1.2.c and ofed_kernel.
Vlad already took 1.2.c, and will I guess take ofed_kernel
after it passes his checks.
--
MST
___
ewg mailing
> Quoting Gleb Natapov <[EMAIL PROTECTED]>:
> Subject: Re: Scalable reliable connection
>
> On Mon, Jul 30, 2007 at 03:50:54PM +0300, Michael S. Tsirkin wrote:
> > With SRC:
> > O(N ^ 2 * J)
> >
> > This is achived by using a single send
> Quoting Tang, Changqing <[EMAIL PROTECTED]>:
> Subject: RE: Scalable reliable connection
>
>
> A send queue can only serve max J jobs within a node. Is it possible to
> make a single send queue to serve all jobs on all nodes ?
How do you propose to do this?
--
MST
___
> Quoting Steve Wise <[EMAIL PROTECTED]>:
> Subject: patches for 1.2.c
>
> Guys,
>
> I have 2 more patches to go in ofed_1_2/ofed_1_2_c.
>
> Is there some grand scheme to the naming of kernel_patches/fixes/* for
> 1.2.c? I noticed a slew of new files for the post-2.6.22 fixes, and
> wondered
> Quoting Erez Zilber <[EMAIL PROTECTED]>:
> Subject: [PATCH 0/2] IB/iser: move open-iscsi crypto functions to
> kernel_addons
>
> The following patches move open-iscsi crypto functions from kernel_patches to
> kernel_addons. By doing so, we also solve a bug in iscsi tx hash that caused
> an oo
> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] Re: OFED 1.2.c-9 is available
>
> > Why under drivers/net rather than drivers/infiniband like all the
> > other drivers ? Does this really need special casing (in libibumad) ?
>
> Tziporet is incorrect. There's nothing f
BTW, if all you want to do is add patches which are applied upstream,
just send the commit ids.
Quoting Steve Wise <[EMAIL PROTECTED]>:
Subject: patches for 1.2.c
Guys,
I have 2 more patches to go in ofed_1_2/ofed_1_2_c.
Is there some grand scheme to the naming of kernel_patches/fixes/* for
1.
ehca backports for kernel.org kernels seem to be broken.
1. Does anyone care enough to fix them? If not we'll disable
ehca in build for these kernels.
2. Could you upload kernels for RHEL4U5 and SLES10 ppc64?
This would make it possible for us to add it to nightly builds.
--
Failed
> Quoting Steve Wise <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] Re: ofa_1_2_c_kernel 20070802-0201 daily build
> status
>
> Also,
>
> Is something broken in the ofed_1_2 branch? I cannot even build against
> the local kernel on the ofa server using the ~vlad/ofed_1_2/linux-2.6
> reposi
Looke here:
/home/vlad/scripts/ofed_1_2
Quoting Steve Wise <[EMAIL PROTECTED]>:
Subject: Re: [ewg] Re: [ofa-general] Re: ofa_1_2_c_kernel 20070802-0201 daily
build status
I'm havin' a bad day.
Can you all help me?
My normal process is to use the build_ofa_kernel.sh script from the
ofabuild r
> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: RFC: SRC API
>
> > - manage SRC domains
>
> OK, I guess, but why do we need so many functions to create, share,
> get shared, put SRC domains?
>
> How about just two functions:
>
> struct ibv_src_domain *ibv_open_src_domain(stru
Vlad?
Quoting Erez Zilber <[EMAIL PROTECTED]>:
Subject: Re: [PATCH 0/2] IB/iser: move open-iscsi crypto functions
to?kernel_addons
Michael S. Tsirkin wrote:
>> Quoting Erez Zilber <[EMAIL PROTECTED]>:
>> Subject: [PATCH 0/2] IB/iser: move open-iscsi crypto functi
> Quoting Erez Zilber <[EMAIL PROTECTED]>:
> Subject: [PATCH 1/2 - v2] IB/iser: move open-iscsi crypto functions to
> kernel_addons (SLES10, RHEL5)
>
> move open-iscsi crypto functions to kernel_addons (SLES10, RHEL5)
>
> Signed-off-by: Erez Zilber <[EMAIL PROTECTED]>
Couldn't apply this.
Apply
> Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH 1/2 - v2] IB/iser: move open-iscsi crypto functions to
> kernel_addons (SLES10, RHEL5)
>
> > Quoting Erez Zilber <[EMAIL PROTECTED]>:
> > Subject: [PATCH 1/2 - v2] IB/iser:
. tmpfile can be used).
- I envision implementing this sharing mechanism in kernel by means
of a per-device tree, with inode as a key and domain object
as a value.
Please comment.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
diff --git a/SRC.txt b/SRC.txt
new file mode
> Quoting Hoang-Nam Nguyen <[EMAIL PROTECTED]>:
> Subject: Re: ofa_1_2_c_kernel 20070802-0201 daily build status
>
> Hello Michael and Vladimir!
> > ehca backports for kernel.org kernels seem to be broken.
> > 1. Does anyone care enough to fix them? If not we'll disable
> >ehca in build for t
Let's not do it this way.
I think the right thing is to implement kmem_cache_zalloc
by means of kmem_cache_allocand memset in kernel_addons.
Quoting Hoang-Nam Nguyen <[EMAIL PROTECTED]>:
Subject: [PATCH ofed-1.2.c] ehca: backport kmem_cache_zalloc() for
2.6.10/sles10/sles10_sp1
Hello Michael
> Only of the job among j2, j3, j4 on remote node n need to create a
> receiving qp2 for j1, right ?
Correct. A single QP can be used to send data to any SRQ that shares the
same domain.
--
MST
___
ewg mailing list
ewg@lists.openfabrics.org
http://list
> Quoting Tang, Changqing <[EMAIL PROTECTED]>:
> Subject: RE: RFCv2: SRC API
>
>
> > +When job j1 needs to transmit to job j2 on remote node n for
> > the first time:
> > +1. Test: does job j1 have an existing connection to some job
> > on node n?
> > +- If no:
> > + j1 creat
> Quoting Tang, Changqing <[EMAIL PROTECTED]>:
> Subject: RE: RFCv2: SRC API
>
>
> > > +When job j1 needs to transmit to job j2 on remote node n for
> > > the first time:
> > > +1. Test: does job j1 have an existing connection to some job
> > > on node n?
> > > +- If no:
> > > +
> Quoting Tang, Changqing <[EMAIL PROTECTED]>:
> Subject: RE: RFCv2: SRC API
>
>
>
> > > OK, I was wrong before, here is my question.
> > >
> > > if remote node n has j2, j3, and j4, and j2 is the job to
> > create qp2
> > > and make connection with qp1 in j1.
> > > if j2 is done before j3 a
> Quoting Tang, Changqing <[EMAIL PROTECTED]>:
> Subject: RE: RFCv2: SRC API
>
>
> > Cleanup:
> > When job j1 does not need to communicate to any jobs on node
> > n, it disconnects qp1 from qp2, and asks j2 to destroy qp2.
> > +
> > +Note: both qp1 and qp2 must exist for the communication to
>
> Quoting Ramachandra K <[EMAIL PROTECTED]>:
> Subject: [PATCH 0/5 VNIC] VNIC patch series for OFED-1.2 and OFED-1.2.c
>
>
> Vlad,
>
> Please apply this VNIC patch series to both the OFED-1.2 and OFED-1.2.c
> branches.
>
> This series contains changes to the VNIC driver for supporting iPath and
> Quoting Kuchimanchi, Ramachandra <[EMAIL PROTECTED]>:
> Subject: RE: [PATCH 0/5 VNIC] VNIC patch series for OFED-1.2 and OFED-1.2.c
>
> -Original Message-----
> From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED]
> Sent: Mon 8/6/2007 11:48 PM
> To: Kuchimanch
> > > So far, the definition of 1.2.c was "1.2 plus bugfixes plus connectx
> > > support".
> >
> > I am not entirely clear about this 1.2.c = 1.2.1 thing.
> > This is my understanding, please correct me if I am wrong - OFED-1.2 is the
> > official OFED release, OFED-1.2.c is a parallel line of dev
Hmm, I thought about it some more.
kmem_cache struct is not exported on recent kernels,
so this might br hard to do.
So I think the patch is probably the right approach, after all.
Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
Subject: Re: [PATCH ofed-1.2.c] ehca: backport kmem_cache_
> Quoting Hoang-Nam Nguyen <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH ofed-1.2.c] ehca: backport kmem_cache_zalloc() for
> 2.6.10/sles10/sles10_sp1
>
> On Tuesday 07 August 2007 07:34, Michael S. Tsirkin wrote:
> > Hmm, I thought about it some more.
> > kme
> Quoting Steffen Persvold <[EMAIL PROTECTED]>:
> Subject: Version number on ibverbs headers
>
> Hi,
>
> Would it be possible to add a version number define to verbs.h to
> reflect the API version ?
>
> For example :
>
> #define IBVERBS_VERSION_MAJOR 1
> #define IBVERBS_VERSION_MINOR 1
>
> ?
>
I'm happy with stuff as it is: the ifdefs make it easy to figure
which version does the backport apply.
BTW, I think the same backport will be needed for older kernels as well, no?
Quoting Hoang-Nam Nguyen <[EMAIL PROTECTED]>:
Subject: Re: [PATCH ofed-1.2.c] ehca: backport kmem_cache_zalloc() fo
-----------
commit 68ba5a0d23460b9580af3afd0dbc35ce87bce089
Author: Michael S. Tsirkin <[EMAIL PROTECTED]>
Date: Tue Aug 7 16:19:30 2007 +0300
Backport kmem_cache_zalloc to kernels <= 2.6.16.
Used by ehca.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
---
diff -
> Quoting Hoang-Nam Nguyen <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH ofed-1.2.c] ehca: backport kmem_cache_zalloc() for
> 2.6.10/sles10/sles10_sp1
>
> On Tuesday 07 August 2007 15:23, Michael S. Tsirkin wrote:
> > > Quoting Hoang-Nam Nguyen <[EMAIL PROTECTED]
> Quoting Hoang-Nam Nguyen <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH ofed-1.2.c] ehca: backport kmem_cache_zalloc() for
> 2.6.10/sles10/sles10_sp1
>
> On Tuesday 07 August 2007 15:23, Michael S. Tsirkin wrote:
> > > Quoting Hoang-Nam Nguyen <[EMAIL PROTECTED]
> Quoting John Russo <[EMAIL PROTECTED]>:
> Subject: RE: OFED 1.2.c status & plans
>
> 1.2.5 would imply that the 1.2 branch has merged with the 1.2c branch.
That's the case. 1.2 branch was merged into 1.2.c branch.
--
MST
___
ewg mailing list
ewg@lis
Is this patch relevant for 1.2.5?
If yes pls feel free to send it to Vlad.
--
MST
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
> Quoting Steve Wise <[EMAIL PROTECTED]>:
> Subject: problems with ofed-1.2.c chelsio low level driver
>
> Michael,
>
> I've discovered that I was really testing the ofed-1.2 cxgb3.ko module
> in my testing 1.2.c regression test. Upon getting a complete 1.2.c
> installed, I'm seeing crashes wi
> Quoting Tang, Changqing <[EMAIL PROTECTED]>:
> Subject: RE: RFCv2: SRC API
>
>
> >
> > > Is there any performance worry to let j2(the first job on a
> > node) to
> > > do all the "work" ?
> >
> > How do you mean?
>
> I mean that j2 has all the QP connections with all other remote jobs, so
> Quoting Steve Wise <[EMAIL PROTECTED]>:
> Subject: problems with ofed-1.2.c chelsio low level driver
>
> Michael,
>
> I've discovered that I was really testing the ofed-1.2 cxgb3.ko module
> in my testing 1.2.c regression test. Upon getting a complete 1.2.c
> installed, I'm seeing crashes wi
> Michael, OFED 1.2 is based on 2.6.21 and OFED 1.2.1 on 2.6.22, did you
> do some 1.2 wrap up of returning fixes to the upstream code? from the
> length of the patch list (specifically, the amount of ipoib and mthca
> ones) it does not seem so, please correct me if I am wrong.
In 1.2.c most pa
> Please pull from git://git.openfabrics.org/~/scm/linux-2.6.git ofed_1_2_c
Is the URL wrong?
--
MST
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
> Quoting Tang, Changqing <[EMAIL PROTECTED]>:
> Subject: RE: RFCv2: SRC API
>
>
> > > I have another question, when using SRQ, or SRC+SRQ, when a
> > completion
> > > is returned by ibv_poll_cq(), is there an easy way to find
> > who sent
> > > this message to me ? 'struct ibv_wc' does not
> Quoting Steve Wise <[EMAIL PROTECTED]>:
> Subject: Re: problems with ofed-1.2.c chelsio low level driver
>
>
>
> Michael S. Tsirkin wrote:
> >>Quoting Steve Wise <[EMAIL PROTECTED]>:
> >>Subject: problems with ofed-1.2.c chelsio low level driver
1 - 100 of 148 matches
Mail list logo
