[openib-general] putting in dead wood for DAPL and similarabomination

[Christoph Hellwig]

On Thu, Mar 03, 2005 at 12:26:33AM +0200, Yaron Haviv wrote:
> > And I've not seen any kernel submittsion for either of them - and
> what's
> > important no single kDAPL application that actually shows any benefit
> > that way.  Volatair's iSER implementation would surely be smaller when
> > directly written to the OpenIB interface, and is already smaller than
> > the whole kDAPL layer.
> 
> Christoph, the reason the iSER code is very thin is that it is using
> kDAPL
> (and Linux iSCSI), it doesn't need to deal with SA calls, CM calls,
> LIDs, GIDs, and a bunch of other things.

Umm, no - it's not small.  In it's current form it's freakin' huge.
That's partially a fault of stupid kDAPL APIs, the cisco iscsi code
and the broken implementation of the iscsi transport switch, but also
because it's pretty bad code. 

The current iSER code is 10928 LOC, add to that 22155 LOC of kDAPL (not
including the actual provider for IB) and 5822 LOC linux-iscsi kernel
code. Compare that to the 25412 LOC total for drivers/infiniband in Linux
2.6.11.

Here's the challenge: if someone gets me the funding I'll write
complete iSER of IB implementation in less than 10k LOC based on the
open-iscsi code if someone gets me the funding.

> Besides being RDMA transport independent DAPL enable people to code to
> RDMA without been intimately familiar with the HW, we saw people coding
> to it in days, Which I can't say the same for Verbs.

Which means they'll hack up total crap code.

> Abstract layers are not new to Linux, Sockets is another type of
> abstraction with multiple protocols/families underneath,

And you forgot that sockets are a really small abstraction layer,
which kDAPL is not.  And even though sockets provide a really nice
abstraction for the data transmission you need to know about address
families for connection establishment and control.  Really bad anology,
you lost :)