netdev - Re: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200807311752.00911.divy@chelsio.com>
Date:	Thu, 31 Jul 2008 17:51:59 -0700
From:	Divy Le Ray <divy@...lsio.com>
To:	"Roland Dreier" <rdreier@...co.com>
Cc:	"Jeff Garzik" <jgarzik@...ox.com>, "Karen Xie" <kxie@...lsio.com>,
	netdev@...r.kernel.org, open-iscsi@...glegroups.com,
	davem@...emloft.net, michaelc@...wisc.edu,
	"Steve Wise" <swise@...ngridcomputing.com>, 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

On Wednesday 30 July 2008 02:35:51 pm Roland Dreier wrote:
>  > * From a networking standpoint, our main concern becomes how this
>  > interacts with the networking stack.  In particular, I'm concerned
>  > based on reading the source that this driver uses "TCP port stealing"
>  > rather than using a totally separate MAC address (and IP).
>  >
>  > Stealing a TCP port on an IP/interface already assigned is a common
>  > solution in this space, but also a flawed one.  Precisely because the
>  > kernel and applications are unaware of this "special, magic TCP port"
>  > you open the potential for application problems that are very
>  > difficult for an admin to diagnose based on observed behavior.
>
> That's true, but using a separate MAC and IP opens up a bunch of other
> operational problems.  I don't think the right answer for iSCSI offload
> is clear yet.
>
>  - R.

Hi Jeff,

We've considered the approach of having a separate IP/MAC addresses to manage
iSCSI connections. In such a context, the stack would have to be unaware of
this iSCSI specific IP address. The iSCSI driver would then have to implement
at least its own ARP reply mechanism. DHCP too would have to be managed
separately. Most network setting/monitoring tools would also be unavailable.

The open-iscsi initiator is not a huge consumer of TCP connections, allocating
a TCP port from the stack would be reasonable in terms of resources in this
context. It is however unclear if it is an acceptable approach.

Our current implementation was designed to be the most tolerable one
within the constraints - real or expected - aforementioned.

Cheers,
Divy

--
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