[ofiwg] ofiwg item: supporting other OS's

[Hefty, Sean]

> > 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.

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