[openib-general] Minutes from DAPL BOF at OpenIB Workshop

Masanori ITOH itoumsn at nttdata.co.jp
Mon Feb 14 03:25:19 PST 2005


Hi,

From: Tom Duffy <tduffy at sun.com>
Subject: Re: FW: [openib-general] Minutes from DAPL BOF at OpenIB Workshop
Date: Thu, 10 Feb 2005 10:51:25 -0800

> On Thu, 2005-02-10 at 18:46 +0100, Christoph Hellwig wrote:
> > Maybe you should lay down the requirement first.
> 
> I'll take a crack at it.  Let me know where I am off base.
> 
> >  - why do we need an intermediate API
> 
> To get things working today with the code that people have already
> written.  To create a proof of concept.
> 
> In any event, I am not proposing this API get kernel inclusion.  Only a
> wider audience than in the sourceforge DAPL project cvs tree.
> 
> >  - what differences does it
> 
> ??
> 
> >  - what devices does it abstract
> 
> IB for now, any other RDMA capable transports later.

AFAIK, Myricom has their own working uDAPL implementation.
  http://www.myri.com/scs/
I think there is no reason why they don't consider kDAPL too.

> >  - what are the users
> 
> NFS over RDMA, maybe -- so RPC.  Anybody else know others?

There is one more publicly available kDAPL consumer, DAFS.

Among the following page, you can find a working DAFS server and client suite
called 'fdafs'. That runs in the kernel space and provides complete
UNIX file I/O semantics.

  http://sourceforge.net/projects/dafs/

Also, it's provided as an open source software, and it's license is BSD/GPL2
dual license.
Unfortunatelly, at this moment, the above fdafs (beta1.0) works on only
2.4 kernel, but we have ported that into 2.6 kernel, and I'm planning
to contribute our work to the community.

-Masanori



More information about the general mailing list