>>>Right?  If so, I don't see why you need the AC_TRY_RUN -- if RDMACM is
easily detectable as to which way it is compiled (because it has, for
example, different fields), then AC_CHECK_DECLS should be enough, right?

RDMACM API has different implementation requirements for its providers:
tcp, af_ib (different structs/fields should be used/passed. different
APIs/hooks should be called for bring-up).

Currently, the RDMACM provider can be selected at compile time only and
mpirun becomes incompatible to other RDMACM providers.

AC_TRY_RUN is a protection that selected provider will be able to
run,otherwise no fallback to other provider will be available for user at
runtime.






On Wed, Mar 12, 2014 at 12:08 AM, Jeff Squyres (jsquyres) <
jsquy...@cisco.com> wrote:

> On Mar 6, 2014, at 12:00 PM, Mike Dubman <mi...@dev.mellanox.co.il> wrote:
>
> > but AF_IB is always declared, regardless of actual presence in the
> kernel.
>
> Right, which is why I don't understand the original comments that you
> can't do a run-time test for it...
>
>
> >
> > On Thu, Mar 6, 2014 at 5:56 PM, Ralph Castain <r...@open-mpi.org> wrote:
> > Let me see if I can help translate. I think the problem here is Jeff's
> comment about a "run time check", which wasn't actually what he is
> proposing here.
> >
> > If you look at Jeff's proposed code, what he is saying is that you don't
> need to use AC_TRY_RUN - you can just build based on whether or not AF_IB
> is declared, and so AC_CHECK_DECLS is adequate. If the resulting code
> fails, then that's an error anyway. So you can just protect the code as he
> shows and be done with it.
> >
> > This would avoid all the warnings we are now receiving on the trunk, and
> do what you need. Make sense?
> >
> >
> >
> >
> >
> > On Thu, Mar 6, 2014 at 7:26 AM, Jeff Squyres (jsquyres) <
> jsquy...@cisco.com> wrote:
> > On Mar 6, 2014, at 4:08 AM, Vasily Filipov <vas...@dev.mellanox.co.il>
> wrote:
> >
> > >> #if HAVE_DECL_AF_IB
> > >>    rc = try_using_af_ib();
> > >>    if (OMPI_ERR_NOT_AVAILABLE == rc) {
> > >>        rc = try_the_other_way();
> > >>    }
> > >> #else
> > >>    rc = try_the_other_way();
> > >> #endif
> > >    I mean I cannot  use "another way" if func call for
> "try_using_af_ib" fails (call for "try_the_other_way()") because RDMACM was
> compiled for AF_IB   usage (different fields in structs, different
> functions prototypes).
> >
> > Ok, that means the implementation is reduced to:
> >
> > #if HAVE_DECL_AF_IB
> >    rc = try_using_af_ib();
> > #else
> >    rc = try_the_other_way();
> > #endif
> >
> > Right?  If so, I don't see why you need the AC_TRY_RUN -- if RDMACM is
> easily detectable as to which way it is compiled (because it has, for
> example, different fields), then AC_CHECK_DECLS should be enough, right?
> >
> > I must be missing something...?
> >
> > --
> > Jeff Squyres
> > jsquy...@cisco.com
> > For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> >
> > _______________________________________________
> > devel mailing list
> > de...@open-mpi.org
> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/03/14306.php
> >
> >
> > _______________________________________________
> > devel mailing list
> > de...@open-mpi.org
> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/03/14307.php
> >
> > _______________________________________________
> > devel mailing list
> > de...@open-mpi.org
> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/03/14308.php
>
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/03/14327.php
>

Reply via email to