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

[Yaron Haviv]

> -----Original Message-----
> From: Roland Dreier [mailto:rolandd at cisco.com]
> Sent: Friday, August 19, 2005 12:24 AM
> To: Yaron Haviv
> Cc: Christoph Hellwig; Grant Grundler; open-iscsi at googlegroups.com;
> openib-general at openib.org
> Subject: Re: [openib-general] [ANNOUNCE] Initial trunk checkin of
> ISERinitiator
> 
>     Yaron> Not every one wants to keep on doing target discovery with
>     Yaron> Python scripts,
> 
> Come on, this is just a stupid statement.  The whole point of putting
> device management in userspace is so that everybody has the
> flexibility to use whatever discovery mechanism they want.

You know there is a small problem in storage, people don't want to just
use what "they want", but rather use standard management, discovery,
Security, HA, etc' which are quite essential for commercial customers  

 
> I agree that the SRP and iSER protocols are basically equivalent at a
> technical level: they both transport SCSI over RDMA.  If you want to
> compare existing implementations, I'd much rather use my SRP driver's
> 1600 lines of code over your 14000+ lines of x86-only iSER on top of
> 10000+ lines of kDAPL (not even counting the iSCSI core).

Not sure how you do your LOC counting or what's included in it
In any case a protocol that is generalized to multiple transports, has
built in discovery, error-recovery, global routing/naming,
authentication, built-in multi-pathing, multi-connection per session,
optimizations for small messages, comprehensive management and
configuration with industry standard APIs, etc'
Probably need to have more LOC than one that just tunnels SCSI command
from one predefined point to another (by the way is DM, CFM and/or
Python included in the 1400 :))

The important things is how many LOC are on the command path and how
optimized it the protocol, this code runs SCSI at 850-900MB/s and on the
same time provides the most comprehensive set of features, and is
managed out of the box with industry standard tools  

A variation of that code runs today on PPC, so I assume it's not an
issue to make sure it runs over PPC 

In any case let aside the religious discussion iSER needs to get into
OpenIB and customers will then decide what ever they want, to get it in
we need:
1. iSER developers to comply to Linux requirements and address any
constructive feedback 
2. have an API that can be used by ULP developers that want to be
transport independent (till then kDAPL would need to be used) 

Yaron

> 
>  - R.