[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080810101935.5c8e8e9a@lxorguk.ukuu.org.uk>
Date: Sun, 10 Aug 2008 10:19:35 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Roland Dreier <rdreier@...co.com>
Cc: Jeff Garzik <jgarzik@...ox.com>,
Steve Wise <swise@...ngridcomputing.com>, davem@...emloft.net,
Divy Le Ray <divy@...lsio.com>, Karen Xie <kxie@...lsio.com>,
netdev@...r.kernel.org, open-iscsi@...glegroups.com,
michaelc@...wisc.edu, daisyc@...ibm.com, wenxiong@...ibm.com,
bhua@...ibm.com, Dimitrios Michailidis <dm@...lsio.com>,
Casey Leedom <leedom@...lsio.com>,
linux-scsi <linux-scsi@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator
> - It doesn't work in theory, because the suggestion (I guess) is that
> the iSCSI HBA has its own MAC and IP and behaves like a separate
The iSCSI HBA is its own system - that is the root of the problem.
> system. But this means that to start with the HBA needs its own ARP,
> ICMP, routing, etc interface, which means we need some (probably new)
> interface to configure all of this. And then it doesn't work in lots
Its another system so surely SNMP ;)
More seriously I do think iSCSI is actually a subtly special case of TOE.
Most TOE disintegrates under carefully chosen "malicious" workloads
because of the way it is optimised, and the lack of security integration
ranges can be very very dangeorus. A pure iSCSI connection is generally
private, single purpose and really is the classic application of "pigs fly
given enough thrust" - which is the only way to make the pig in question
(iSCSI) work properly.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists