[openib-general] Re: Porting DAPL to OpenIB Gen 2

Mon Feb 28 12:48:35 PST 2005

As promised during the call today, here is a link to the patches Tom
Duffy sent:

http://sourceforge.net/mailarchive/forum.php?thread_id=6549863&forum_id=13070

On Mon, 28 Feb 2005, James Lentini wrote:

>
> Below are my meeting notes:
>
> Porting DAPL to OpenIB
> ======================
> Meeting Notes
> Date: 2/28/2005
> Time: 11:30 AM EST
>
> Attendees:
> James Lentini       jlentini at netapp.com
> Dror Goldenberg     gdror at mellanox.co.il
> Itamar Rabenstein   itamar at mellanox.co.il
> Arkady Kanevsky     arkady at netapp.com
> Hal Rosenstock      halr at voltaire.com
> Aviram Gutman       aviram at mellanox.co.il
> Arlin Davis         arlin.r.davis at intel.com
> Tom Duffy           tduffy at sun.com
> Yaron Haviv         yaronh at voltaire.com
> Or Gerlitz          ogerlitz at voltaire.com
> Steve Sears         sjs at netapp.com
> Bob Woodruff        robert.j.woodruff at intel.com Tom Talpey 
> talpey at netapp.com
>
> + Enumerate Tasks:
>  - uDAPL
>    who: Arlin Davis at Intel
>
>    No 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 Voltaire
>
>   Initially 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 at openib.org and cc'ing 
> James Lenitni (jlentini at netapp.com). 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: jlentini at netapp.com
>>> Network Appliance            phone: 781-768-5359
>>> 375 Totten Pond Rd.            fax: 781-895-1195
>>> Waltham, MA 02451-2010        main: 781-768-5300
>>> 
>>> 
>> 
>