RE: Framing Discussion

[Douglas Otis <dotis@sanlight.net>]

David,

A content directed copy modifies TCP.  Posting a header at fixed intervals
may be a means of allowing a standard TCP implementation to remain
compliant, but the intent of this requirement should include a complete
description of the API and consider the security consequences of allowing
this activity to take place out of sequence on a NIC adapter.  One would
expect inter-operability to be an important aspect in acceptance of this
type of modification.

Doug

> This issue is one of how SCSI interfaces to the
> operating system.  Operating systems issue a
> SCSI read and provide a buffer (e.g., a page
> from the file buffer cache or the like) into
> which the data is to be read.  SCSI and Fibre
> Channel HBAs are capable of taking the data
> directly off the bus/cable/wire/fiber and putting
> it into exactly the right place in the correct
> buffer.  The approach Mohan outlines below reads
> the data into some buffer and then has to copy
> it into the right place when parsing of the
> iSCSI header(s) reveals what that place is.
> The design goal behind the framing discussion
> is avoidance of that copy.  In contrast to the
> typical case for NICs and TCP/IP, read data
> buffers for SCSI data are usually *not*
> interchangeable.
>
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>
> > -----Original Message-----
> > From:	Mohan Parthasarathy [SMTP:Mohan.Parthasarathy@eng.sun.com]
> > Sent:	Tuesday, December 19, 2000 6:06 PM
> > To:	ips@ece.cmu.edu; marjorie_krueger@hp.com
> > Subject:	Re: Framing Discussion
> >
> > Hi Marjorie,
> >
> > The section on "How can we accomplish direct data placement",
> > seems to assume that there is a separate buffer allocated
> > by the iscsi layer to receive the data from the network.
> > Is this an implicit assumption on how iscsi will be built ?
> >
> > I can see iscsi layer sitting on top of TCP posting iscsi
> > commands, and receiving buffers from the network as they
> > come. Assume the NIC has a pool of buffers for the
> > iscsi connection. When the data comes from the network, i
> > can assume that the NIC is able to parse the TCP/IP headers
> > and locate the right buffer pool for receiving data. As the
> > data is received, it can be returned to the iscsi layer
> > which can interpret the iscsi header and the length and hence
> > the data following the iscsi header and also more iscsi headers
> > that follow it. In this model, i don't see any difficulty
> > in data placement unless i am missing something.
> >
> > -mohan
> >
> > > From owner-ips@ece.cmu.edu Tue Dec 19 11:12:06 2000
> > > X-Authentication-Warning: ece.cmu.edu: majordom set sender to
> > owner-ips@ece.cmu.edu using -f
> > > From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
> > > To: "Ips Reflector (E-mail)" <ips@ece.cmu.edu>
> > > Subject: Framing Discussion
> > > Date: Tue, 19 Dec 2000 10:08:05 -0700
> > > MIME-Version: 1.0
> > >
> > > Attached are the minutes of the technical meeting to discuss framing
> > held
> > > 11/29/2000 in San Jose, CA.  I created it with Acrobat 4.0, a free
> > reader
> > > can be installed from
> > http://www.adobe.com/products/acrobat/readstep2.html
> > >
> > > This document contains the mathmatical support for the general feeling
> > that
> > > we won't be able to do > 1 Gbps over TCP without some framing help.
> > >
> > > Marjorie Krueger
> > > Networked Storage Architecture
> > > Networked Storage Solutions Org.
> > > Hewlett-Packard
> > > tel: +1 916 785 2656
> > > fax: +1 916 785 0391
> > > email: marjorie_krueger@hp.com
> > >
>