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

[Caitlin Bestler]

> -----Original Message-----
> From: rdma-developers-admin at lists.sourceforge.net 
> [mailto:rdma-developers-admin at lists.sourceforge.net] On 
> Behalf Of Woodruff, Robert J
> Sent: Thursday, May 26, 2005 5:12 PM
> To: Caitlin Bestler
> Cc: Venkata Jagana; rdma-developers at lists.sourceforge.net; 
> openib-general at openib.org
> Subject: [Rdma-developers] RE: [openib-general] OpenIB and 
> OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux
> 
> >RNIC-PI is at least an attempt at providing full control over both 
> >iWARP and IB while making as much common as possible.
> 
> Where were you last year when the IB verbs header files/API 
> were being discussed.
> Seems like that was the time to discuss new APIs. 
> Now it is a bit late to propose something totally new like RNIC-PI.
> The best thing to do now is to try to influence the existing 
> code base to meet your needs rather than recommend a totally new API.
> And the best way to do that is to make changes to the code 
> that exists or write new code and send in patches to the list 
> so that it can be discussed. 
> 
> woody
> 


OpenIB's announced charter was IB specific. There was no 
announcement that the intent was to define *all* RDMA
services.

Where were you when RNIC-PI was discussing these issues?
It's announced charter *was* to be transport neutral and
OS neutral.

But that's water under the bridge. The fact is that both
IB and iWARP vendors have existing development efforts 
and any realistic plan will recognize that. The question
is to what degree code can be made common without requiring
anyone to start over from scratch.

That may involve merely defining critical interfaces with
the rest of the OS, and then splitting into two transport
dependent sub-systems. Or it may be possible to come up
with a transport-neutral low level API.

The latter goal is indeed desirable, but I am skeptical
that it is compatible with the needs of either IB or iWARP
vendors to be making forward progress on actual code today.

It may make more sense to agree on the fundamental interfaces
to the rest of the kernel, and on approximately what transport
neutral verbs might look like someday, and then to develop
in parallel until there is two branches of code that both
work before attempting to merge them.