Yes this is Solaris only. OFED has not bought back the IBV_ACCESS_SO
flag. Not sure they ever will.
On 02/16/11 08:15, Jeff Squyres wrote:
Oracle --
Is this really only specific to Solaris? More comments below about
configure.m4.
On Feb 16, 2011, at 12:37 AM, dk...@osl.iu.edu wrote:
is PCI ordering (i.e., unreliable) on all hardware -- or am I
wrong?
On Feb 16, 2011, at 8:59 AM, Don Kerr wrote:
I considered that but I wanted to guard against future OFED inclusion. Removing
the Solaris check is easy enough.
On 02/16/11 08:49, Jeff Squyres wrote:
On Feb 16, 2011, at 8:29 AM
Hello Sebastian,
Sounds like you are using the openib btl as a starting point, which is a
good place to start. I am curious if you are indeed using a new
interconnect (new hardware and protocol) or if it is requirements of the
3D-torus network that are not addressed by the openib btl that are
I intend to make the change suggested in this ticket to the trunk. The
change does not impact single rail, tested with openib btl, case and
does improve dual rail case. Since it does involve performance and I am
adding a OB1 mca parameter just wanted to check if anyone was interested
or had
George,
Were you suggesting that the proposed new parameter
"max_rdma_single_rget" be set by the individual btls similar to
"btl_eager_limit"? Seems to me to that is the better approach if I am
to move forward with this.
-DON
On 10/06/09 11:14, Don Kerr wrote:
I agr
is difficult. And for the case of
multiple btls which are also different component types, however unlikely
that is, a pml setting will not be optimal for both.
-DON
george.
On Oct 7, 2009, at 10:19 , Don Kerr wrote:
George,
Were you suggesting that the proposed new parameter
.
On Oct 8, 2009, at 11:01 , Don Kerr wrote:
On 10/07/09 13:52, George Bosilca wrote:
Don,
The problem is that a particular BTL doesn't have the knowledge
about the other selected BTL, so allowing the BTLs to set this limit
is not as easy as it sound. However, in the case two identical BTLs
On 10/08/09 17:14, Don Kerr wrote:
George,
This is an interesting approach although I am guessing the changes
would be wide spread and have many performance implications. Am I
wrong in this belief?
My point here is that if this is going to have as many performance
implications as I think
It would be difficult for me to attend this afternoon. Tomorrow is much
better for me.
-DON
George Bosilca wrote:
I'm available this afternoon.
george.
On Jun 7, 2007, at 2:35 PM, Galen Shipman wrote:
Are people available today to discuss this over the phone?
- Galen
On Jun 7,
Just a heads up.
I have merged the uDAPL BTL from the trunk to a tmp repository of v1.2
branch. Can be found in
https://svn.open-mpi.org/svn/ompi/tmp/dkerr_udaplv1.2_rdma
if anyone is interested in testing before I submit the CMR to bring into
1.2.4.
Main goal of CMR: Improve uDAPL BTL
Yes I use opal_show_help in other places but that is an all or nothing
proposition. I think the ability to be verbose or quiet can be very
usefull to end users and that is what I need at the moment.
-DON
Jeff Squyres wrote:
On Jul 9, 2007, at 9:58 AM, Don Kerr wrote:
You want
Through mca parameters one can select the use of shared receive queues
in the openib btl, other than having fewer queues I am wondering what
are the benefits of using this option. Can anyone eleborate on using
them vs the default?
, at 12:29 PM, Don Kerr wrote:
Through mca parameters one can select the use of shared receive queues
in the openib btl, other than having fewer queues I am wondering what
are the benefits of using this option. Can anyone eleborate on using
them vs the default
not help in many other cases.
Is there any distinction by the size of the message. If the "M"
parameter is set high does the openib btl post this many recv buffers
for the SRQ on both QPs? Or are SRQs only created on one of the QPs?
On Jul 12, 2007, at 12:29 PM, Don
Jeff Squyres wrote:
On Jul 12, 2007, at 1:18 PM, Don Kerr wrote:
- So if you want to simply eliminate the flow control, choose M high
enough (or just a total number of receive buffers to post to the SRQ)
that you won't ever run out of resources and you should see some
speedup from lack
All,
I have noticed an issue in the 1.2 branch when mpi_preconnect_all=1. The
one way communication pattern (ranks either send or receive from each
other) may not fully establish connection with peers. Example, if I have
a 3 process mpi job and rank 0 does not do any mpi communication after
How would the openib btl handle the following scenario:
Two nodes, each with two ports, all ports are on the same subnet and switch.
Would striping occur over 4 connections or 2?
If 2 is it equal distribution or are both local ports connected to the
same remote port?
Thanks
-DON
Rich,
Do the ompi_free_list changes impact the sm btl? Solaris SPARC sm btl
seems to have an issue starting with last nights put back but I have not
looked into it yet.
-DON
Richard Graham wrote:
R16641 should have fixed the regression. Anyone using
ompi_free_list_t_ex() and providing
Gleb,
Another question. What about the case of one node with 2 ports and one
node with one port. Does the open ib btl allow the side with 2 ports to
establish two endpoints to the single remote port?
-DON
Gleb Natapov wrote:
On Thu, Nov 01, 2007 at 11:15:21AM -0400, Don Kerr wrote
both, I was thinking of listing what I think are multi-rail requirements
but wanted to understand what the current state of things are
Jeff Squyres wrote:
Don --
Are you asking what *does* it do, or what *should* a BTL do?
On Nov 9, 2007, at 1:09 PM, Don Kerr wrote:
Gleb,
Another
Jeff Squyres wrote:
On Nov 9, 2007, at 1:24 PM, Don Kerr wrote:
both, I was thinking of listing what I think are multi-rail
requirements
but wanted to understand what the current state of things are
I believe the OF portion of the FAQ describes what we do in the v1.2
series
Looking at the list of new features for OFED 1.3 and seeing that support
for XRC went into the trunk I am curious if support for additional OFED
1.3 features will be included, or plan to be included in Open MPI?
I am looking at the list of features here:
Thanks Steve, Jeff, Pasha, this is the kind of information I was looking
for.
-DON
Pavel Shamis (Pasha) wrote:
I plan to add IB APM support (not something specific to OFED)
Don Kerr wrote:
Looking at the list of new features for OFED 1.3 and seeing that support
for XRC went
Hi,
After searching, about the only thing I can find on xrc is what it
stands for, can someone explain the benefits of open mpi's use of xrc,
maybe point me to a paper, or both?
TIA
-DON
.
In the openib paper you may see more details about XRC. If you need more
details about XRC implemention
in openib blt , please let me know.
Instead
Don Kerr wrote:
Hi,
After searching, about the only thing I can find on xrc is what it
stands for, can someone explain the benefits of open mpi's use
This was brought to my attention once before but I don't see this
message so I just plain forgot about it. :-(
uDAPL defines its pointers as uint64, "typedef DAT_UINT64 DAT_VADDR",
and pval is a "void *" which is why the message comes up. If I remove
the cast I believe I get a different
I believe btl_open_iwarp.c is making platform specific calls. I don't
have jdmason's email and wanted to send this note out before todays con
call.
btl_openib_iwarp.c
#include
getifaddrs()
Just want to make sure what I think I see is true:
Linux build. openib btl requires ptmalloc2 and ptmalloc2 requires posix
threads, is that correct?
Thanks Jeff. Thanks Brian.
I ran into this because I was specifically trying to configure with
"--disable-progress-threads --disable-mpi-threads" at which point I
figured, might as well turn off all threads so I added
"--without-threads" as well. But can't live without mpi_leave_pinned so
Can anyone set my expectations with their real world experiences
regarding building Open MPI on one release of Linux and running on another.
If I were to...
Build OMPI on Redhat 4, will it run on later releases of Redhat, e.g.
Redhat 5?
Build OMPI on Suse 9, will it run on later releases of
It appears that the mca_btl_openib.so has a dependency on libibcm.so.
Is this necessary?
have configury to disable this behavior (and *not* build
RDMACM and/or IBCM support).
Do you have a problem / need to disable building support for IBCM?
On Jul 2, 2008, at 12:02 PM, Don Kerr wrote:
It appears that the mca_btl_openib.so has a dependency on libibcm.so.
Is this necessary
to
disable/enable *CM via config flags.
On Jul 3, 2008, at 2:52 AM, Don Kerr wrote:
I did not think it was required but it hung me up when I built ompi
on one system which had the ibcm libraries and then ran on a system
without the ibcm libs. I had another issue on the system without
ibcm libs
Last I looked the OpenIB BTL relied on the short eager rdma buffers
being written in order? Is this still the case?
If so, how is this handled when iWARP is underneath the User Verb API
and not Mellonox IB HCAs?
For something as fundamental as launch do we still need to specify the
component, could it just be "launch_agent"?
Jeff Squyres wrote:
Sounds good to me. We've done similar things in other frameworks --
put in MCA base params for things that all components could use. How
about
Jeff Squyres wrote:
On Jul 15, 2008, at 7:30 AM, Ralph Castain wrote:
Minor clarification: we did not test RDMACM on RoadRunner.
Just for further clarification - I did, and it wasn't a particularly
good
experience. Encountered several problems, none of them overwhelming,
hence
my
All,
I just did a commit (-r19217) which I believe will require an autogen.
Since I was reminded that this is not good citizen behavior for the
middle of the day I will now start figuring out how to back this out
unless someone beats me to it.
-DON (with head hung low)
h. Damage is done. Leave it in.
We'll whip you later. ;-)
On Aug 7, 2008, at 12:04 PM, Don Kerr wrote:
All,
I just did a commit (-r19217) which I believe will require an
autogen. Since I was reminded that this is not good citizen
behavior for the middle of the day I will now start figurin
38 matches
Mail list logo
