lkml.org 
[lkml]   [2008]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Integration of SCST in the mainstream Linux kernel


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


\
 
 \ /
  Last update: 2008-02-04 20:49    [from the cache]
©2003-2011 Jasper Spaans