<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 8, 2016 at 1:20 PM, Hefty, Sean <span dir="ltr"><<a href="mailto:sean.hefty@intel.com" target="_blank">sean.hefty@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> > As a discussion item for the next ofiwg, the topic has come up (again)<br>
> about supporting other operating systems, specifically Windows and<br>
> Solaris.<br>
><br>
> I would imagine that supporting Solaris with the configury/build/sockets<br>
> providers wouldn't be too difficult...?<br>
><br>
> I don't know much about Windows to comment on it.<br>
<br>
</span>In my experience the biggest difference working on Windows versus Linux is handling fd's.  I think Windows supports BSD like sockets, but they also provide an asynchronous socket interface, which would be preferable if we cared about performance on Windows.<br>
<br></blockquote><div><br></div><div>You are right that the big issue is the type of the socket descriptor.  MPI has an issue because of this (<a href="https://github.com/mpi-forum/mpi-issues/issues/13">https://github.com/mpi-forum/mpi-issues/issues/13</a>).<br></div><div><br></div><div>Is anyone from Microsoft involved right now?  The Microsoft MPI folks might be able to help if no one else from Microsoft is currently involved.</div><div><br></div><div>Jeff</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The primary target for any Windows provider would be NetworkDirect, which is very limited in what capabilities it supports.  But then some customers just want to know if the app _can_ run on windows.<br>
<span class=""><br>
> > At least two development teams have asked about support outside of<br>
> Linux.  The desire is to code only to libfabric, with it dealing with<br>
> differences in the underlying interfaces.  This is partially driven by the<br>
> socket provider support inside libfabric, which allows for applications to<br>
> remove their support for sockets.<br>
> ><br>
> > This in turn is driving the need for the sockets provider to focus on<br>
> performance and scalability, rather than just functionality, which was the<br>
> original goal.<br>
><br>
> Is it worth forking the sockets provider -- one for "simple" correctness<br>
> (and not performance), and another optimized provider for sockets?<br>
<br>
</span>I've started work on a 'utility' provider library that can be used by basic providers to support more of the API set.  This library will be focused on supporting a well-defined set of features in the most performant way.  (I call it a library, but it's really just a collection of routines and templates that's derived from the existing providers.)  This is being done in conjunction with a UDP based provider, which gives us a simple starting point and, potentially, a more scalable socket-based solution.  (We'll see.)<br>
<br>
Along these lines, I've brought up the topic of having a shared memory provider as part of this effort.  This should provide a better indicator on how specific implementation choices impact performance.  Since with sockets, even medium performance improvements get lost in the overhead.<br>
<br>
So, I would delay forking the TCP sockets provider until the code can be refactored, it can be compared against a built up UDP provider, and we have a better way to measure where performance gains can be made.<br>
<span class=""><font color="#888888"><br>
- Sean<br>
</font></span><div class=""><div class="h5">_______________________________________________<br>
ofiwg mailing list<br>
<a href="mailto:ofiwg@lists.openfabrics.org">ofiwg@lists.openfabrics.org</a><br>
<a href="http://lists.openfabrics.org/mailman/listinfo/ofiwg" rel="noreferrer" target="_blank">http://lists.openfabrics.org/mailman/listinfo/ofiwg</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div>
</div></div>