Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756712AbYHMXMs (ORCPT ); Wed, 13 Aug 2008 19:12:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754372AbYHMXMg (ORCPT ); Wed, 13 Aug 2008 19:12:36 -0400 Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:44615 "EHLO sunset.davemloft.net" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1754285AbYHMXMf (ORCPT ); Wed, 13 Aug 2008 19:12:35 -0400 Date: Wed, 13 Aug 2008 16:12:37 -0700 (PDT) Message-Id: <20080813.161237.10205799.davem@davemloft.net> To: rdreier@cisco.com Cc: rick.jones2@hp.com, jgarzik@pobox.com, swise@opengridcomputing.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 From: David Miller In-Reply-To: References: <20080813.150831.193391799.davem@davemloft.net> X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1327 Lines: 32 From: Roland Dreier Date: Wed, 13 Aug 2008 16:03:15 -0700 > OK, I admit you could make something work -- add hooks for the low-level > driver to ask the iSCSI initiator where PDU boundaries are so it can > resync when something is evicted from the flow cache, have the initiator > format its tags in a special way to encode placement data, etc, etc. > The scheme does bring to mind Alan's earlier comment about pigs and > propulsion, though. There would need to be _NO_ hooks into the iSCSI initiator at all. The card would land the block I/O data onto the necessary page boundaries and the iSCSI code would just be able to thus use the pages directly and as-is. It would look perfectly like normal TCP receive traffic. No hooks, no special cases, nothing like that. > In any case, as I said in the part of my email that you snipped, the > real issue is not designing hypothetical hardware, but deciding how to > support the Chelsio, Broadcom, etc hardware that exists today. The same like we support TOE hardware that exists today. That is, we don't. -- 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/