On Mon, 2008-02-04 at 11:44 -0800, Linus Torvalds wrote: > > On Mon, 4 Feb 2008, Nicholas A. Bellinger wrote: > > > > While this does not have anything to do directly with the kernel vs. > > user discussion for target mode storage engine, the scaling and latency > > case is easy enough to make if we are talking about scaling TCP for 10 > > Gb/sec storage fabrics. > > I would like to point out that while I think there is no question that the > basic data transfer engine would perform better in kernel space, there > stll *are* questions whether > > - iSCSI is relevant enough for us to even care ... > > - ... and the complexity is actually worth it. > > That said, I also tend to believe that trying to split things up between > kernel and user space is often more complex than just keeping things in > one place, because the trade-offs of which part goes where wll inevitably > be wrong in *some* area, and then you're really screwed. > > So from a purely personal standpoint, I'd like to say that I'm not really > interested in iSCSI (and I don't quite know why I've been cc'd on this > whole discussion) The generic target mode storage engine discussion quickly goes to transport specific scenarios. With so much interest in the SCSI transports, in particuarly iSCSI, there are lots of devs, users, and vendors who would like to see Linux improve in this respect. > and think that other approaches are potentially *much* > better. So for example, I personally suspect that ATA-over-ethernet is way > better than some crazy SCSI-over-TCP crap, Having the non SCSI target mode transports use the same data IO path as the SCSI ones to SCSI, BIO, and FILE subsystems is something that can easily be agreed on. Also having to emulate the non SCSI control paths in a non generic matter to a target mode engine has to suck (I don't know what AoE does for that now, considering that this is going down to libata or real SCSI hardware in some cases. There are some of the more arcane task management functionality in SCSI (ACA anyone?) that even generic SCSI target mode engines do not use, and only seem to make endlessly complex implement and emulate. But aside from those very SCSI hardware specific cases, having a generic method to use something like ABORT_TASK or LUN_RESET for a target mode engine (along with the data path to all of the subsystems) would be beneficial for any fabric. > but I'm biased for simple and > low-level, and against those crazy SCSI people to begin with. Well, having no obvious preconception (well, aside from the email address), I am of the mindset than the iSCSI people are the LEAST crazy said crazy SCSI people. Some people (usually least crazy iSCSI standards folks) say that FCoE people are crazy. Being one of the iSCSI people I am kinda obligated to agree, but the technical points are really solid, and have been so for over a decade. They are listed here for those who are interested: http://www.ietf.org/mail-archive/web/ips/current/msg02325.html > > So take any utterances of mine with a big pinch of salt. > > Historically, the only split that has worked pretty well is "connection > initiation/setup in user space, actual data transfers in kernel space". > > Pure user-space solutions work, but tend to eventually be turned into > kernel-space if they are simple enough and really do have throughput and > latency considerations (eg nfsd), and aren't quite complex and crazy > enough to have a large impedance-matching problem even for basic IO stuff > (eg samba). > > And totally pure kernel solutions work only if there are very stable > standards and no major authentication or connection setup issues (eg local > disks). > > So just going by what has happened in the past, I'd assume that iSCSI > would eventually turn into "connecting/authentication in user space" with > "data transfers in kernel space". But only if it really does end up > mattering enough. We had a totally user-space NFS daemon for a long time, > and it was perfectly fine until people really started caring. Thanks for putting this into an historical perspective. Also it is interesting to note that the iSCSI spec (RFC-3720) was ratified in April 2004, so it will be going on 4 years soon, which pre-RFC products first going out in 2001 (yikes!). In my experience, the iSCSI interopt amongst implementations (espically between different OSes) has been stable since about late 2004, early 2005, with interopt between OS SCSI subsystems (espically talking to non SCSI hardware) being the slower of the two. --nab - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
