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) 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, but I'm biased for simple and low-level, and against those crazy SCSI people to begin with. 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. Linus - 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
