On Fri, Nov 20, 2009 at 01:38:59AM +0200, Or Gerlitz wrote:
yes, this would be simply not supportable, think about that, you want
to hand your customers with a code which didn't pass review nor
acceptance by the Linux IB stack maintainers (Roland and Sean), say,
next a crash happens at this
As far as core APIs go, the patch set introduces 2 basic additions
rather than changes:
- A new ABI function to resolve gids to macs - ib_get_mac()
- A new kernel ib_device function to get the port transport -
ib_get_port_transport().
There are no changes to the Verbs API.
All the address
On Mon, Nov 23, 2009 at 10:11:21AM +0200, Eli Cohen wrote:
Would like to fix a typo: I meant bellow:
Saying that the patch set did not go through a review process would
**be** inaccurate.
On Fri, Nov 20, 2009 at 01:38:59AM +0200, Or Gerlitz wrote:
yes, this would be simply not supportable,
90% of the changes are either in the mlx4 driver, or self-contained in
the rdmaoe flow of the cma, which handles rdmaoe addressing and
connection setup.
The rest of the changes indeed touch various locations of the stack, but
they are either definitions or follow the same logic:
if
facts... the patch set sent from downtown Yoqne'am isn't an addition of feature
turns out that some folks from the Mellanox RD group found this
sentence insulting, and I am apologizing for that.
Mentioning the geographic location of the developers didn't come to
serve why I find the patch
In the past few months of review, the responsibility for rdmaoe
addressing was moved to the rdmacm.
So, any future addressing enhancements can be confined to the rdmacm
module without breaking existing APIs.
RFC 3041 deals with static global IP addresses on the Internet,
especially for portable
This email was generated automatically, please do not reply
git_url: git://git.openfabrics.org/ofed_1_5/linux-2.6.git
git_branch: ofed_kernel_1_5
Common build parameters:
Passed:
Passed on i686 with linux-2.6.18
Passed on i686 with linux-2.6.21.1
Passed on i686 with linux-2.6.19
Passed on
Jonathan Perkins schrieb:
Sorry for the late reply. You should be able to use mpirun_rsh in order
to avoid setting up mpd.
It works fine.
But i have to give -np.
Back to Topic:
When i try to compile an MPE Code i get:
u...@head:~$ mpicc mandelbrot_mpe.c -o Apfel
/tmp/ccwpw6so.o: In
FWIW: the dealbreaker for me is that we're already at 1.5rc2. By
OFED's own rules, new features are not to be allowed. Or you can
reset the release clock and target Jan/Feb.
Mellanox already has their own OFED distribution -- since there
appears to be strong desire to get this stuff
On Mon, Nov 23, 2009 at 12:27:23PM +0100, Stefan Kuhne wrote:
Jonathan Perkins schrieb:
Sorry for the late reply. You should be able to use mpirun_rsh in order
to avoid setting up mpd.
It works fine.
But i have to give -np.
Back to Topic:
When i try to compile an MPE Code i get:
Jeff Squyres wrote:
FWIW: the dealbreaker for me is that we're already at 1.5rc2. By
OFED's own rules, new features are not to be allowed. Or you can
reset the release clock and target Jan/Feb.
Mellanox already has their own OFED distribution -- since there
appears to be strong desire to
Liran Liss wrote:
The patches don't change the logic of existing flows at all, so we are
not risking *anything* in terms of the stability of the current stack.
I understand that this is your assessment of the situation, looking on the
series present
at the ofed1.5 rdmaoe branch in a black box
Is this code new ? We've been evaluating versions of it since before
June/2009.
We are currently testing with OFED-RDMAoE-1.5-20091116-0620.tgz.
Our plans are to move from OFED 1.4.2 to OFED 1.5.x in June/2010..
It takes us this long to complete internal testing.
Has anyone else done any
Is this code new ? We've been evaluating versions of it since before
June/2009.
We are currently testing with OFED-RDMAoE-1.5-20091116-0620.tgz.
Our plans are to move from OFED 1.4.2 to OFED 1.5.x in June/2010..
It takes us this long to complete internal testing.
Has anyone else done any
ewg-boun...@lists.openfabrics.org wrote on 11/22/2009 02:36:32 AM:
Pradeep Satyanarayana wrote:
Roland Dreier wrote:
Thanks... in any case I applied all 9 of the patches in this series.
Thanks for pulling all this together.
Sean, Thanks a lot for pulling it all together. Can we
We at OSU have done testing of MVAPICH2 1.4 against the OFED-RDMAoE branch
mentioned below. Everything works well. In fact, we made a formal release
of MVAPICH2 1.4 with RDMAoE support last month.
Thanks,
DK
Is this code new ? We've been evaluating versions of it since before
June/2009.
We
In any case, this is not a correctness issue that prohibits
experimentation with rdmaoe multicast on any network today.
I agree -- nothing prevents experimentation. I am just leery about
making invasive changes to the core stack in the absence of any
documented design for IBoE (that I've
Vlad,
Please pull from:
ssh://v...@sofa.openfabrics.org/~swise/scm/ofed_kernel.git ofed_1_5
This pulls in an important upstream bug fix and adjusts the backport
files accordingly.
Thanks,
Steve.
---
[sw...@build linux-2.6]$ git show --stat
c5dfd17460415cfd982821c097c1a3385e65e36e
18 matches
Mail list logo
