Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755255AbYHNBxM (ORCPT ); Wed, 13 Aug 2008 21:53:12 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751479AbYHNBwy (ORCPT ); Wed, 13 Aug 2008 21:52:54 -0400 Received: from smtp.opengridcomputing.com ([209.198.142.2]:54489 "EHLO smtp.opengridcomputing.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751137AbYHNBwx (ORCPT ); Wed, 13 Aug 2008 21:52:53 -0400 Message-ID: <48A38FEF.6090500@opengridcomputing.com> Date: Wed, 13 Aug 2008 20:52:47 -0500 From: Steve Wise User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: David Miller CC: tom@opengridcomputing.com, rdreier@cisco.com, rick.jones2@hp.com, jgarzik@pobox.com, divy@chelsio.com, kxie@chelsio.com, netdev@vger.kernel.org, open-iscsi@googlegroups.com, michaelc@cs.wisc.edu, daisyc@us.ibm.com, wenxiong@us.ibm.com, bhua@us.ibm.com, dm@chelsio.com, leedom@chelsio.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator References: <20080813.161237.10205799.davem@davemloft.net> <48A389DB.9050002@opengridcomputing.com> <20080813.183755.72334968.davem@davemloft.net> In-Reply-To: <20080813.183755.72334968.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1321 Lines: 32 David Miller wrote: > From: Tom Tucker > Date: Wed, 13 Aug 2008 20:26:51 -0500 > > >> Can you explain how this "information" somehow doesn't qualify as >> "state". Doesn't the next expected sequence number at the very least >> need to be updated? una? etc...? >> >> Could you also include the "non-state-full" information necessary to do >> iSCSI header digest validation, data placement, and marker removal? >> > > It's stateless because the full packet traverses the real networking > stack and thus can be treated like any other packet. > > The data placement is a side effect that the networking stack can > completely ignore if it chooses to. > How do you envision programming such a device? It will need TCP and iSCSI state to have any chance of doing useful and productive placement of data. The smarts about the iSCSI stateless offload hw will be in the device driver, probably the iscsi device driver. How will it gather the information from the TCP stack to insert the correct state for a flow into the hw cache? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/