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
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