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

[Grant Grundler]

On Thu, Aug 18, 2005 at 10:42:22PM +0300, Yaron Haviv wrote:
> > Yeah, I was wondering about that. When I was off on vacation
> > in July (and OLS), kDAPL was committed to the svn repository.
> > Has anyone reviewed that?
> > 
> > I was under the impression kDAPL would never make it into
> > the openib.org source tree. Or has something changed?
> 
> Grant, 
> 
> Currently kDAPL is the ONLY layer that can be abstracted over both IB &
> iWarp, due to the different CM model of the two interconnects
> iSER and NFS/RDMA are common to both IB & iWarp and are implemented to
> run on both.

I think I understand why kDAPL exists.
But doesn't there need to be some iwarp code under
src/linux-kernel/infiniband/ulp/kdapl ?
I only see "ib".

Let me rephrase my question since your answer doesn't really
address what I was asking:
	Any reason why kDAPL might not get pushed upstream?

Some of the original objections were it's an unnecessary layer that
interfers with performance and bloats the linux kernel source tree.
Arguments about portability between user/kernel and portability
across OSs won't (or didn't) fly in the linux kernel community.
Has that perception about kDAPL change since March?

If kDAPL for any reason doesn't get pushed upstream to kernel.org,
we effectively don't have iSER or NFS/RDMA in linux. 
Since I think without them, linux won't be competitive in the
commercial market place.


> 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.


> Also appreciate your productive feedback on the code,

s/productive/constructive/ :^)

"productive" would have been to provide a patch to implement
what I was whining about. :^)

(I'm just teasing in case that's not obvious)


> the team will address it

I'd suggest addressing Christoph's issues first since they are "deeper".
This includes his comments today and his original comments here:
	http://openib.org/pipermail/openib-general/2005-March/thread.html

Look for "putting in dead wood for DAPL" on that page.
I've mostly only commented on superficial things (mostly Codingstyle).


{/rant on}
If people used RFC compliant email clients, the emails would be
archived all under one thread in that web page....but it's not. :^(
It's multiple threads.
{/rant off}

thanks,
grant