> -----Original Message----- > From: Roland Dreier [mailto:[EMAIL PROTECTED] > Sent: Friday, August 19, 2005 12:24 AM > To: Yaron Haviv > Cc: Christoph Hellwig; Grant Grundler; [EMAIL PROTECTED]; > [email protected] > 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. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
