[ofiwg] ofiwg item: supporting other OS's
jeff.science at gmail.com
Fri Jan 8 13:45:00 PST 2016
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 (
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.
> 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
> > socket provider support inside libfabric, which allows for applications
> > 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
> > 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
jeff.science at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ofiwg