[Openib-windows] OpenIB and Windows

[Fab Tillier]

Greetings Paul,

> From: Paul Baxter [mailto:paul.baxter at dsl.pipex.com]
> Sent: Tuesday, December 06, 2005 3:06 AM
> 
> OpenIB's web site currently states its goal is to provide
> a Linux stack for Infiniband.

Yes, the website needs to be updated to reflect its broader scope.  Even a
mention of the Windows project on the home page would be terrific.  I haven't
had much time to devote to website maintenance, so even
http://windows.openib.org is a little lackluster.  It's good to have the
feedback, though, as that might help coax us into action to remedy the
situation.

> In the last few months I've become aware of the fledgling
> Windows 'port' of the OpenIB codebase and wondered what
> relationship it has with OpenIB's mandate.

It's not a port, as the only code that is shared between the two projects is the
OpenSM code.  Everything else is a different codebase.  The Windows project
evolved from Intel's now defunct SourceForge IBAL project, while the Linux gen2
stack is a fresh, from-the-ground-up implementation targeted closely to the
Linux OS.  As the Windows stack progresses it is likely to diverge more from
Linux as we take advantage of the facilities provided to us by the Windows OS.
The API will likely change to match the Windows kernel and user APIs more
closely too, with the ultimate goal of making the IB stack look and feel as if
it was well integrated into the OS.

> I would love to see such a port, if only to convince
> more people to use infiniband but wonder whether it will
> become a more public part of OpenIB's work e.g. on its
> website. Perhaps it is merely a case of not wishing to
> pre-announce something that is not yet ready for a wider
> audience?

I think it's a fall out of being a developer-heavy organization, with the
developers spending more time on writing code than authoring web pages.  The
Windows project is certainly not immature, with a broad scope of upper level
protocols.  In fact, the more people using it the better, as it will help shake
out any bugs.

> My understanding is that you are hoping to release
> a 'gen1' minimalist release early next year. Will this
> then become part of OpenIB's output and available under
> similar terms?

Yes, the goal is to have a release that at a minimum includes all components
necessary to support Microsoft's upcoming Compute Cluster Solution in advance of
the official CCS launch.  That means that we're targeting 1Q06.  It won't quite
be a minimalist release, though, and will include at a minimum IPoIB and Winsock
Direct (WSD) along with the underlying components necessary to support them.
The access layer is full-featured today.  Following the first release we'll be
adding support for SRP (currently in Beta) and SDP (currently in Alpha), as well
as a variety of user-mode tools including OpenSM (currently in Beta). 

The code is available today from svn://windows.openib.org, as are binary
releases (even Beta releases) are available from the
http://windows.openib.org/downloads/.  There isn't any sort of installer (yet),
and IB vendors are currently encouraged to repackage the binaries in their own
releases.  Debug symbols are also available for the OpenIB binaries, and a
symbol server for use with WinDbg has been setup to facilitate debug.

> Perhaps someone could sketch out the plan? In particular,
> would it be possible to clarify how it will relate to the
> Linux codebase and functionality, if at all.

The codebase is going to be completely different.  However, the functionality is
going to be similar where it makes sense.  Verbs for one will be quite similar.
As the stack moves towards a second generation design to more tightly integrate
into the Windows environment, we'll be working to leverage design elements from
the Linux stack and applying them to the Windows stack to maximize similarities.

As far as I know, however, there isn't any intention for a reciprocal
arrangement - there is no work being done that I know of to make the Linux APIs
match the design of the existing Windows ones (for things like SA query,
multicast, etc).

The licensing of the two stacks is different, with the Windows stack being
BSD-only (at least all the kernel components), so we have to exercise care in
not pulling in any GPL code from the Linux stack.

> For instance similar APIs aren't always appropriate but
> is there a mandate to maintain similar functional groupings
> even if a few parameter types need changing or will this
> be a radically different codebase.

There is no such mandate, but I would personally like to see the APIs as close
to one another as possible.  If not at the syntax level at least at the
conceptual level so that moving from one OS to the other isn't burdensome.

> There is no reason to mirror Linux if its at the expense
> of Windows performance or maintainability but there would
> be advantages to users if conceptually using say a
> communications manager had broadly the same set of calls.

The issue here is that the Windows stack's API has been around for longer than
the Linux stack's API.  The existing APIs, CM included, aren't similar.  There
are plans to change these to more closely follow the architecture of the Linux
stack, so long as it makes sense for Windows.  As we make these design changes
we'll be posting RFCs to the mailing list.  If you see anything that you don't
like, or would like something changed or that's missing, please let us know.

Let me know if you have any other questions.

Thanks,

- Fab