I think so. The one who is most familiar with btl/ofi is Arm (CCed in this 


> On Apr 24, 2019, at 9:41 AM, Heinz, Michael William 
> <michael.william.he...@intel.com> wrote:
> So, 
> Would it be worthwhile for us to start doing test builds now? Is the code 
> ready for that at this time?
>> -----Original Message-----
>> From: devel [mailto:devel-boun...@lists.open-mpi.org] On Behalf Of
>> Nathan Hjelm via devel
>> Sent: Friday, April 12, 2019 11:19 AM
>> To: Open MPI Developers <devel@lists.open-mpi.org>
>> Cc: Nathan Hjelm <hje...@me.com>; Castain, Ralph H
>> <ralph.h.cast...@intel.com>; Yates, Brandon <brandon.ya...@intel.com>
>> Subject: Re: [OMPI devel] Intel OPA and Open MPI
>> That is accurate. We expect to support OPA with the btl/ofi component. It
>> should give much better performance than osc/pt2pt + mtl/ofi. What would
>> be good for you to do on your end is verify everything works as expected
>> and that the performance is on par for what you expect.
>> -Nathan
>>> On Apr 12, 2019, at 9:11 AM, Heinz, Michael William
>> <michael.william.he...@intel.com> wrote:
>>> Hey guys,
>>> So, I’ve watched the videos, dug through the release notes, and
>> participated in a few of the weekly meetings and I’m feeling a little more
>> comfortable about being a part of Open MPI - and I’m looking forward to it.
>>> But I find myself needing to look for some direction for my participation
>> over the next few months.
>>> First - a little background. Historically, I’ve been involved with IB/OPA
>> development for 17+ years now, but for the past decade or so I’ve been
>> entirely focused on fabric management rather than application-level stuff.
>> (Heck, if you ever wanted to complain about why OPA management
>> datagrams are different from IB MADs, feel free to point the finger at me,
>> I’m happy to explain why the new ones are better… ;-) ) However, it was only
>> recently that the FM team were given the additional responsibility for
>> maintaining / participating in our MPI efforts with very little opportunity 
>> for a
>> transfer of information with the prior team.
>>> So, while I’m looking forward to this new role I’m feeling a bit
>> overwhelmed - not least of which because I will be unavailable for about 8
>> weeks this summer…
>>> In particular, I found an issue in our internal tracking systems that says 
>>> (and
>> I may have mentioned this before…)
>>> OMPI v5.0.0 will remove osc/pt2pt component that is the only component
>> that MTLs use (PSM2 and OFI). OMPI v5.0.0 is planned to be released during
>> summer 2019 (no concrete dates).  https://github.com/open-
>> mpi/ompi/wiki/5.0.x-FeatureList. The implications is that none of the MTLs
>> used for Omni-Path will support running one sided MPI APIs (RMA).
>>> Is this still accurate? The current feature list says:
>>> If osc/rdma supports all possible scenarios (e.g., all BTLs support the RDMA
>> methods osc/rdma needs), this should allow us to remove osc/pt2pt (i.e.,
>> 100% migrated to osc/rdma).
>>> If this is accurate, I’m going to need help from the other maintainers to
>> understand the reason this is being done, the scope of this effort and where
>> we need to focus our attention. To deal with the lack of coverage over the
>> summer, I’ve asked a co-worker, Brandon Yates to start sitting in on the
>> weekly meetings with me.
>>> Again, I’m looking forward to both the opportunity of working with an open
>> source team, and the chance to focus on the users of our software instead of
>> just the management of the fabric - I’m just struggling at the moment to get
>> a handle on this potential deadline.
>>> ---
>>> Mike Heinz
>>> Networking Fabric Software Engineer
>>> Intel Corporation
>>> _______________________________________________
>>> devel mailing list
>>> devel@lists.open-mpi.org
>>> https://lists.open-mpi.org/mailman/listinfo/devel
>> _______________________________________________
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://lists.open-mpi.org/mailman/listinfo/devel

devel mailing list

Reply via email to