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

Masanori ITOH itoumsn at nttdata.co.jp
Mon Feb 14 03:26:55 PST 2005


Hi,

From: Christoph Hellwig <hch at lst.de>
Subject: Re: FW: [openib-general] Minutes from DAPL BOF at OpenIB Workshop
Date: Sun, 13 Feb 2005 15:29:06 +0100

> On Sun, Feb 13, 2005 at 03:25:24PM +0100, Christoph Hellwig wrote:
> > On Sun, Feb 13, 2005 at 10:37:12AM +0200, Dan Bar Dov wrote:
> > > > I don't know who "we" here is, but we as the kernel developer 
> > > > community certainly disagree.
> > > 
> > > So how do you describe scsi mid layer?
> > > Scsi mid layer is exaclty a unifying API that hides the specific hardware device drivers from the upper layer abstractions.
> > > The kdapl model is identical to the scsi model - a single in-kernel API that hides different hardware specific implementations of RDMA.
> > 
> > It's not really analogue.  In SCSI the hardware (or at least the drivers)
> > all speak the same protocol (in a few different revisions), and the scsi
> > midlayer and upper level drivers implement most of that protocol.  The
> > LLDDs program the different hardware implementing this protocol.
> > 
> > See the SAM-2 or SAM-3 documents for details.
> 
> The right analogy for kDAPL in scsi land would be the CAM standard from
> T10.org that tried to specifiy in-kernel interfaces for SCSI.  While a
> few Operating Systems tried to model their stack afer CAM (Digital Unix,
> FreeBSD), it soon became clear that the standard isn't implementable 1:1
> in a real life system, was a hidrance in implementing clean and lean
> driver and had no chance following the development of new SAM
> substandards.

I think there is a great difference between T10.org and DAT activity.
In case of T10.org, I guess the development style was like
spec. first and then implementations. This sometimes causes problems like
you mentioned.
But, the DAT activity is more like IETF style. Here, I mean
DAT spec. people have been brushed up their documents getting feedbacks
from implementation people. 
Thus, I believe the current kDAPL spec. can be a good start point of
the discussion.

-Masanori



More information about the general mailing list