[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080813.190521.224523380.davem@davemloft.net>
Date: Wed, 13 Aug 2008 19:05:21 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: swise@...ngridcomputing.com
Cc: tom@...ngridcomputing.com, rdreier@...co.com, rick.jones2@...com,
jgarzik@...ox.com, divy@...lsio.com, kxie@...lsio.com,
netdev@...r.kernel.org, open-iscsi@...glegroups.com,
michaelc@...wisc.edu, daisyc@...ibm.com, wenxiong@...ibm.com,
bhua@...ibm.com, dm@...lsio.com, leedom@...lsio.com,
linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator
From: Steve Wise <swise@...ngridcomputing.com>
Date: Wed, 13 Aug 2008 20:52:47 -0500
> How do you envision programming such a device?
There should be no special programming.
> It will need TCP and iSCSI state to have any chance of doing useful
> and productive placement of data.
The card can see the entire TCP stream, it doesn't need anything
more than that. It can parse every packet header, see what kind
of data transfer is being requested or responded to, etc.
Look, I'm not going to design this whole friggin' thing for you guys.
I've stated clearly what the base requirement is, which is that the
packet is fully processed by the networking stack and that the card
merely does data placement optimizations that the stack can completely
ignore if it wants to.
You have an entire engine in there that can interpret an iSCSI
transport stream, you have the logic to do these kinds of things,
and it can be done without managing the connection on the card.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists