Date: July 2004
Ultimate goal is the upstream acceptance into Linux. It is an ongoing process to achieve this goal. Cooperation with community brings responsibility and privilege: The responsibility for high code quality and the privilege to "become part of the grid". There is a lot of benefit from being part of it - the code is maintained, the project stays up-to-date...
Have an agreed-upon high-level architecture by end of September'04. Having a block diagram level architecture as a goal by that time. Want to avoid multiple proprietary, non-interoperable stacks. Building up trust in the group is important.
Some reconciliation will be needed between iWARP and IB, given that we want to support transport-independent APIs. We should try to abstract out transport-independent areas. IB implementations may create an inertia regarding the code base. Try to avoid bifurcation of access layer code bases. We don't need to solve the reconciliation between iWARP and IB right away, but should take it into account.
We are/should be monitoring RNIC-PI. If they make good progress within a few months, great. Otherwise, we'll have to think about alternatives to speed up the process.
Use multiple licenses in addition to GPL.
Development model - start with interested parties then make it completely open after agreement on clean architecture.
Establish separate WG on the architecture. If code development goes, maintainers will make sure that code follows architecture.
Code Maintainer per module, volunteers per module needed.
Make the project open to all contributors (but not companies) with equal rights. Code maintainers are to be chosen among the contributors. Voting is incompatible to Open Source goal. The true Open Source type of development does not provide a voting procedure. Some level of control is necessary, if project partners are committing resources (people, money, ...).
The project should learn from the mistakes being made in other open source projects.
Interactions with the OpenIB project and stack convergence - Try to gain from similarities like common interfaces (DAPL, IT-API, ..) and potentially similar code components but we should not force both projects to become one project soon. Merging should be secondary goal. We should in any case establish a common interface to both stacks.
OpenRDMA should have a goal to educate the community – For example, Some education materials on RDMA technology should be prepared and be made available.
Legacy Socket Apps shouldn't be supported
IT-API should support both dependent and independent transport modes
Both uDAPL and IT-API should be supported through common access layer with separate shim layers.
openRDMA do not need to provide the user level APIs direct access (i.e Bypassing the kernel) to hardware unlike in IB. RNIC-PI is the preferred path for both kernel and user level APIs.
With regard to the routing of completions (i.e. the event notifications) between the kernel and user, there do not need to be a private interface between the driver and user access layer but rather use the kernel access layer.
Agreed to have a thin intermediate user level access layer to hide the underlying kernel implementation details to avoid the changes in the APIs every time there are changes in kernel code and also to address some inefficiencies through optimizations provided.
Agreed to collect all potential major issues (such as TOE service, kernel stack intrusion, ...) internally before going public to discuss with maintainers
Regarding tcp endpoint transition – It is required to support both kernel based connection setup (delayed transition to RNIC) and RNIC-based tcp setup (implicit transition). This topic is going to be influenced by the actual specification work of the RNIC-PI WG of the ICSC. we hope to get RNIC-PI support for both approaches.
The design should be such that the RDMA APIs (DAPL, IT-API etc) should be able to share common Access Layer objects.
openRDMA project should support simultaneous loading and coexistence of multiple vendor device drivers. It is agreed that this is a very general requirement and will be supported.
openRDMA project should aim to support OS version independent RDMA enablement support. Yes, this will be supported from a RNIC-PI stand point. Having OS version independent PI support would be good for the device drivers porting.
RDMA OS support be enabled, only when requested for, in multi-purpose RNIC devices.
ULPs such as NFSeR and iSER are considered as level 1 priority and SDP over iWARP should be a level 2 priority of openRDMA project need to pick up any development of these ULPs.
Large set of DAPL test tools are available for uDAPL and kDAPL and they could be used to test over iWARP stack.
openRDMA should try to provide DAPL support since the current set of applications are using uDAPL (as opposed to IT-API). But how would DAPL be supported? Couple of options are available but one option is to support it directly with the user access layer and other option is going through IT-API. The direct support of uDAPL is preferred. Need to verify the uDAPL documentation to see how it is interfaced at its bottom layer.
DAPL is currently supported on multiple OSes. Some vendors are interested in creating a Linux version of DAPL and open source it through GPL if DAT collaborative is agreeable.
Support of MPI should be provided over uDAPL or directly using Verbs Interface
Convergence of IB and RDMA interfaces - Ultimate goal is to have a single interface supporting both IB and iWARP i.e. the convergence path need to be defined for VAPI/IB and RNIC-PI/iWARP. The current expectation is that we can have a single user access layer supporting IB and iWARP interfaces to have single uDAPL or MPI API implementations supporting both types of fabrics.
The OpenRDMA group is not for changing the verbs spec but only provide an implementation of a Verbs interface.
There was general agreement that members need to track the progress of the RNIC PI effort within ICSC, to ensure that there is no conflict between RNIC-PI & OpenRDMA. openRDMA should identify and work on those subareas where there are no discussions happening within RNIC-PI to avoid any duplicate effort.
Some vendors may have some open source code running on Linux and will probably contribute it
Driver code check-in into open repository - check in the driver code at the level of vendor preference (either object or source code)