Re: storage over IP (was Re: [PLEASE-TESTME] Zerocopy networking patch,

Re: storage over IP (was Re: [PLEASE-TESTME] Zerocopy networking patch,

[Cacophonix]

I haven't tracked the IP storage group too closely, but was at the San Diego IETF
where there were some interesting debates about this issue. 

There is a write-up at http://ips.pdl.cs.cmu.edu/mail/msg02598.html

Now I'm not sure if I agree with some of the assumptions. And I share your concern 
about using multiple tcp streams.

Thoughts?

cheers,
karthik


--- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > <http://www.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-01.txt>
> > show that both use TCP/IP.  TCP/IP has variable length headers (or am i on
> > crack?), which totally complicates the receive path.
> 
> TCP has variable length headers. It also prevents you re-ordering commands
> in the stream which would be beneficial. I've not checked if the draft uses
> multiple TCP streams but then you have scaling questions. 
> 
> Alan
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

storage over IP (was Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1)

[dean gaudet]

On Tue, 9 Jan 2001, Ingo Molnar wrote:

> On Mon, 8 Jan 2001, Rik van Riel wrote:
>
> > Having proper kiobuf support would make it possible to, for example,
> > do zerocopy network->disk data transfers and lots of other things.
>
> i used to think that this is useful, but these days it isnt.

this seems to be in the general theme of "network receive is boring".
which i mostly agree with... except recently i've been thinking about an
application where it may not be so boring, but i haven't researched all
the details yet.

the application is storage over IP -- SAN using IP (i.e. gigabit ethernet)
technologies instead of fiberchannel technologies.  several companies are
doing it or planning to do it (for example EMC, 3ware).

i'm taking a wild guess that SCSI over FC is arranged conveniently to
allow a scatter request to read packets off the FC NIC such that the
headers go one way and the data lands neatly into the page cache (i.e.
fixed length headers).  i've never investigated the actual protocols
though so maybe the solution used was to just push a lot of the detail
down into the controllers.

a quick look at the iSCSI specification
<http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-02.txt>, and the
FCIP spec
<http://www.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-01.txt>
show that both use TCP/IP.  TCP/IP has variable length headers (or am i on
crack?), which totally complicates the receive path.

the iSCSI requirements document seems to imply they're happy with pushing
this extra processing down to a special storage NIC.  that kind of sucks
-- one of the benefits of storage over IP would be the ability to
redundantly connect a box to storage and IP with only two NICs (instead of
4 -- 2 IP and 2 FC).

is NFS receive single copy today?

anyone tried doing packet demultiplexing by grabbing headers on one pass
and scattering the data on a second pass?

i'm hoping i'm missing something.  anyone else looked around at this stuff
yet?

-dean

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: storage over IP (was Re: [PLEASE-TESTME] Zerocopy networking patch,

[Alan Cox]

> fixed length headers).  i've never investigated the actual protocols
> though so maybe the solution used was to just push a lot of the detail
> down into the controllers.

The stuff I have access to (MPT fusion) pushes the FC handling down onto the
board. Basically you talk scsi and IP to it (See drivers/message/fusion in
-ac)

> <http://www.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-01.txt>
> show that both use TCP/IP.  TCP/IP has variable length headers (or am i on
> crack?), which totally complicates the receive path.

TCP has variable length headers. It also prevents you re-ordering commands
in the stream which would be beneficial. I've not checked if the draft uses
multiple TCP streams but then you have scaling questions. 

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/