On Fri, Jan 8, 2016 at 1:20 PM, Hefty, Sean <[email protected]> wrote:
> > > As a discussion item for the next ofiwg, the topic has come up (again) > > about supporting other operating systems, specifically Windows and > > Solaris. > > > > I would imagine that supporting Solaris with the configury/build/sockets > > providers wouldn't be too difficult...? > > > > I don't know much about Windows to comment on it. > > 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. > > You are right that the big issue is the type of the socket descriptor. MPI has an issue because of this ( https://github.com/mpi-forum/mpi-issues/issues/13). 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. Jeff > 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. > > > > At least two development teams have asked about support outside of > > Linux. The desire is to code only to libfabric, with it dealing with > > differences in the underlying interfaces. This is partially driven by > the > > socket provider support inside libfabric, which allows for applications > to > > remove their support for sockets. > > > > > > This in turn is driving the need for the sockets provider to focus on > > performance and scalability, rather than just functionality, which was > the > > original goal. > > > > Is it worth forking the sockets provider -- one for "simple" correctness > > (and not performance), and another optimized provider for sockets? > > 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.) > > 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. > > 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. > > - Sean > _______________________________________________ > ofiwg mailing list > [email protected] > http://lists.openfabrics.org/mailman/listinfo/ofiwg > -- Jeff Hammond [email protected] http://jeffhammond.github.io/
_______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
