[Rdma-developers] Re: [openib-general] OpenIB and OpenRDMA:Convergence on common RDMAAPIs and ULPs for Linux

[Ryan, Jim]

Please see some comments below which I'm offering on my own but I hope
speaking fairly and responsibly for the "steering committee" (more
correctly the Board) of OpenIB.

 

Jim Ryan, Chairman, OpenIB

 

________________________________

From: openib-general-bounces at openib.org
[mailto:openib-general-bounces at openib.org] On Behalf Of Venkata Jagana
Sent: Tuesday, May 31, 2005 4:44 PM
To: Grant Grundler
Cc: Sukanta ganguly; rdma-developers at lists.sourceforge.net;
openib-general at openib.org; rdma-developers-admin at lists.sourceforge.net
Subject: Re: [Rdma-developers] Re: [openib-general] OpenIB and
OpenRDMA:Convergence on common RDMAAPIs and ULPs for Linux

 


> I've been advocating rdmaconsortium folks submit patches
> against openib.org for several reasons:

Probably, you meant openrdma.org opensource project but not
a standards setting body (i.e. RDMA consortium - 
http://www.rdmaconsortium.org/home <http://www.rdmaconsortium.org/home>
) :)

> 1) start with a code base that works
> 2) start with a code base that is already upstream
> 3) get advice/guidance from people who know how to collaborate
>    in an open source environment.
> 
> I thought (2) was the most important...but now I have to wonder
> if it's really (3). 

You are mistaken. I know people in the OpenRDMA community have 
worked with the opensource projects before and they 
know how to play and collaborate in an open source environment. 
The early part of the work in openrdma is in fact, a true example 
of that effort (which you may disagree with but having worked with
several other opensource projects and with OpenIB, we have
solved the issues which other projects including OpenIB have faced)
and the next phase of work which is of course the code development, 
a key aspect of broader community effort. 

I think we are diverging from the real issue - the fundamental
differences 
in the views of each community in how we can solve this common problem
of
supporting multiple RDMA fabrics, which is what we need to focus on.

> 
> > Just having OpenIB subsume control of anything iWARP or impose only 
> > DAPL for all RDMA infrastructure because it just happens to be there
today 
> > seems rather stifling.  Just stating that some OpenIB steering group
is 
> > somehow empowered to decide this for Linux is also rather strange.
> 
> AFAICT the openib.org steering group doesn't control the content
> of the svn.openib.org source tree. It manages things like web content,
> overall charter, etc ....

Don't agree. If you have read the email thread on this discussion, 
you would find that steering committee need to decide whether openIB 
should work on including the support for iWARP. Not that I am 
supporting this idea -:)

In the opensource world, developers should/will have the freedom to 
add what they want to do but of course, the acceptance of their
contributions
into mainline is completely a different matter.



[Ryan, Jim] The Board of OpenIB is considering a proposal to formally
support iWARP in addition to InfiniBand. I believe formally expanding
our charter would signal developers and industry participants that
OpenIB is undertaking this work as a complement to what we're doing with
InfiniBand.

A couple of additional points. First, no one is saying OpenIB should
"subsume control of anything iWARP" - that's quite a stretch from OpenIB
entertaining code submissions for iWARP as part of our Linux development
activities. Second, the statement the "steering committee" doesn't
control the content of the source tree is correct in this arena. The
steering committee maintains the web site and other administrative
activities, including, potentially, sending the message to the industry
of our interest and support of iWARP. It does not control the activity
of the open community - I don't think we could if we wanted to, and we
don't.

To be as clear as possible, if the steering committee were to vote
against this proposed expanded charter, the open community participants
may well proceed with these activities on their own.

.....hope that helps, Jim


Thanks
Venkat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050602/1903c6d7/attachment.html>