Below are my meeting notes:
Porting DAPL to OpenIB ====================== Meeting Notes Date: 2/28/2005 Time: 11:30 AM EST
Attendees:
James Lentini [EMAIL PROTECTED]
Dror Goldenberg [EMAIL PROTECTED]
Itamar Rabenstein [EMAIL PROTECTED]
Arkady Kanevsky [EMAIL PROTECTED]
Hal Rosenstock [EMAIL PROTECTED]
Aviram Gutman [EMAIL PROTECTED]
Arlin Davis [EMAIL PROTECTED]
Tom Duffy [EMAIL PROTECTED]
Yaron Haviv [EMAIL PROTECTED]
Or Gerlitz [EMAIL PROTECTED]
Steve Sears [EMAIL PROTECTED]
Bob Woodruff [EMAIL PROTECTED] Tom Talpey [EMAIL PROTECTED]
+ Enumerate Tasks:
- uDAPL
who: Arlin Davis at IntelNo additional volunteers.
We agreed to keep SourceForge structure (provider and platform
abstraction layers) for uDAPL. Openib user space software lacks
a CM and name resolution APIs. uDAPL will need to work around
these deficiencies (by hard coding connections, etc.) at first. uDAPL will require kernel support for mapping the cookies used
by shared registrations. - kDAPL
who: Itamar Rabenstein at Mellanox
Hal Rosenstock at VoltaireInitially we will work with current verbs abstraction layer. Once OpenIB support is functional and stable, we will begin removing the verbs and platform abstraction layers.
MTHCA does not support all of DAPL required features (memory windows, virtual memory registration, etc.). When will these be supported?
[AI] James Lentini: inquire about above
- name resolution interface
who: ?The kernel APIs are evolving. User will be done second.
- Linux coding style
who: everyone Documentation is in every linux kernel in
"Documentation/CodingStyle" and "Documentation/SubmittingPatches"
Tom Duffy gave James Lentini an overview of the types of changes
at the OpenIB workshop. No apparent interest in making a single
individual responsible for this. We expect to receive feedback
from the community once code is in OpenIB tree. - kDAPL API changes for Linux coding style
who: James Lentini and Arkady Kanevsky at NetApp First step is changing header files. We would like to keep
old code from breaking while updates are being made. One option is
to use a temporary set of typedefs while the headers are in flux.[AI] James Lentini: send Tom Duffy's patches to attendees
- tools (dapltest, dat conformance test, etc.)
who: volunteers?DAT Conformance test needs recode. No volunteers to do this work.
- documentation (user guide, design guides, etc.)
who: volunteers? everyone? We only touched on this briefly as time was running out. James
would like written record of design decisions for posterity.+ Appropriate location for DAPL source code in OpenIB tree. Split kernel and user space code? Split registry and provider?
Do we want to split kernel and user space code? Majority are in favor of split. License issues are simpler (i.e. if the OpenIB community ever wanted to add the LGPL for user components this would be feasible). Intel's experience with past Linux projects suggest that this is the correct decision. Keeping them together would mean lots of kernel changes affect user code.
We will keep the registry code in the same general location as the provider code. If other RDMA transports pop up, we will adjust this.
Initially, we will put DAPL code on a branch and move to mainline when it is ready. Initial OpenIB checkin will be based on the soon to be created DAPL Gamma 3.1 drop (this drop will be Gamma 3.0 + a few fixes + GPL option).
[AI] James Lentini: create tar of current CVS and send to Tom,
Arlin, Itamar, and Hal. They will get started with this while
Gamma 3.1 is being prepared.+ Procedure for checkins
Use the same procedure for other parts of the OpenIB tree. Submitter
will send an email containing patch to openib-general@openib.org and cc'ing James Lenitni ([EMAIL PROTECTED]). Submitter should indicate that it is for dapl by placing the text "[DAPL]" in the subject.
NOTE: We didn't discuss this on the phone, but checkins should also have a "signed-off by" line (in accordance with OpenIB practices).
+ SourceForge synchronization
Proposal would be to have patches sent to both OpenIB and SourceForge.
The files in OpenIB will have 2 licenses and the SourceForge will have 3 licenses.
Little enthusiasm for this on the phone. Two counter proposals made:
1) submit code with CPL license 2) re-license code with CPL
[AI] Tom Duffy: At the next OpenIB board meeting, ask if it is a
violation of OpenIB bylaws to have dapl files licensed under
a third license (CPL)? [AI] James Lentini: try to attend board meeting to answer questions.
[AI] James Lentini: investigate option #2 with lawyers. Note: early
indications are that this is not feasible.
On Mon, 28 Feb 2005, James Lentini wrote:
Below is an agenda for the call:
+ Additional Items?
+ Enumerate Tasks: - uDAPL who: Arlin Davis at Intel
- kDAPL who: Itamar Rabenstein at Mellanox Voltaire for CM related features
- Linux coding style who: everyone
- kDAPL API changes for Linux coding style who: James Lentini and Arkady Kanevsky at NetApp
- tools (dapltest, dat conformance test, etc.) who: volunteers?
- documentation (user guide, design guides, etc.) who: volunteers? everyone?
+ Appropriate location for DAPL source code in OpenIB tree. Split kernel and user space code? Split registry and provider?
+ Procedure for checkins
+ SourceForge synchronization
On Thu, 24 Feb 2005, James Lentini wrote:
Yesterday the DAT Collaborative voted to add the GPL license to the DAPL Source Forge reference implementation. We are now in a position to begin porting the DAPL SourceForge project to OpenIB. I could like to hold a conference call to help plan and divide up this work.
Date: Monday, February 28 Time: 11:30 AM EST Domestic: 888-827-8686 International: 303-928-2620 Conference ID: 1125043
James Lentini email: [EMAIL PROTECTED] Network Appliance phone: 781-768-5359 375 Totten Pond Rd. fax: 781-895-1195 Waltham, MA 02451-2010 main: 781-768-5300
_______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
