Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Mar 2005 09:15:08 -0800 (PST) Received: from colo.lackof.org (colo.lackof.org [198.49.126.79]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2UHF3sP011364 for ; Wed, 30 Mar 2005 09:15:03 -0800 Received: from localhost (localhost [127.0.0.1]) by colo.lackof.org (Postfix) with ESMTP id 96D41298052; Wed, 30 Mar 2005 10:16:48 -0700 (MST) Received: from colo.lackof.org ([127.0.0.1]) by localhost (colo.lackof.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31783-04; Wed, 30 Mar 2005 10:16:47 -0700 (MST) Received: by colo.lackof.org (Postfix, from userid 27253) id 464DD29802F; Wed, 30 Mar 2005 10:16:47 -0700 (MST) Date: Wed, 30 Mar 2005 10:16:47 -0700 From: Grant Grundler To: Alex Aizman Cc: open-iscsi@googlegroups.com, "'Rick Jones'" , "'netdev'" , ksummit-2005-discuss@thunk.org Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics Message-ID: <20050330171647.GC30849@colo.lackof.org> References: <1112138018.1088.31.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Home-Page: http://www.parisc-linux.org/ User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/795/Wed Mar 30 01:58:09 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lackof.org X-Virus-Status: Clean X-archive-position: 1044 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: grundler@parisc-linux.org Precedence: bulk X-list: netdev Content-Length: 1276 Lines: 24 On Tue, Mar 29, 2005 at 06:28:25PM -0800, Alex Aizman wrote: > If we continue to fall back into TCP-will-eventually-recover mentality > iSCSI, or at least a "soft" non-offloaded iSCSI over regular non-TOE TCP, > will not be able to compete with FC, which uses determinstic credit-based > flow control. That non-determinism is a bigger issue, while a corner case > like swap device happenning to be iSCSI-remote is just that, a corner case > that helps to highlight and bring the general problem to the foreground. There is no way to fix the "non-determinism" inherent in a transport. DoS attacks depend on this. The transport has to be deterministic (flow control, QoS) to avoid anything that looks like a DoS (e.g. OOM). Parallel SCSI suffers the same problem. The priority on the transport is dictated by SCSI ID. Low priority SCSI IDs can (and do) get starved with as few as 5 RAID storage enclosures. The problem is the initiator (host controller) can send data but then like iSCSI, the command times out when the completion doesn't arrive. For parallel SCSI, the SCSI target device never wins SCSI bus arbitration to send back the completion. People can configure the system so this isn't a problem. But it means not having as much storage per SCSI bus. hth, grant