[ofiwg] ofiwg item: supporting other OS's

[Jeff Hammond]

On Fri, Jan 8, 2016 at 1:20 PM, Hefty, Sean <sean.hefty at intel.com> 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
> ofiwg at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/ofiwg
>



-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofiwg/attachments/20160108/00ebffe4/attachment.html>