[openib-general] [ANNOUNCE] Initial trunk checkin of ISERinitiator

[Yaron Haviv]

> -----Original Message-----
> From: Grant Grundler [mailto:iod00d at hp.com]
> Sent: Thursday, August 18, 2005 7:41 PM
> To: Yaron Haviv
> Cc: Grant Grundler; Christoph Hellwig; open-iscsi at googlegroups.com;
> openib-general at openib.org
> Subject: Re: [openib-general] [ANNOUNCE] Initial trunk checkin of
> ISERinitiator
> 
> 
> > Until OpenIB will define another layer that can be used for both,
there
> > is no other viable alternative for iSER to be implemented on top
> > In future if a new common API/Layer will be provided iSER can change
to
> > support it
> 
> I've understood that the openib.org Verbs API can be changed to make
> it "transport neutral" - ie support RNICs.  RNIC vendors don't seem
> to be interested in submitting patches for that. Did someone think
> they can drop kDAPL into openib.org SVN and roland would automatically
> push that into kernel.org?
> 
> I'm not convinced of that and worry that iSER and NFS/RDMA won't
> make it into kernel.org as things stand now.
> 

Grant,

The Verb portion deals with the data path operations (after the
connection was established), the connection establishment process is
very different 
IB CM is implemented on top of the verbs, an iWarp specific CM would
also need to be developed in parallel (interacts with the TCP stack ..),
and common ULPs need a single mechanism to use both (in the DAPL case a
BSD like API using IP addresses)

Again I'm not saying kDAPL is the ultimate solution or that it will last
in its current form, its just the only thing we can use today, if
someone would come with a better implementation we can just change iSER 

In one of the previous threads I suggested building a hybrid layer that
uses the current verb APIs for verb type operations, and the DAPL code
for the connection establishment, resulting in a simpler/shorter code,
this would present a middle ground addressing the concerns on both sides


Yaron