[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4890C287.60508@pobox.com>
Date: Wed, 30 Jul 2008 15:35:35 -0400
From: Jeff Garzik <jgarzik@...ox.com>
To: Karen Xie <kxie@...lsio.com>
CC: netdev@...r.kernel.org, open-iscsi@...glegroups.com,
davem@...emloft.net, michaelc@...wisc.edu,
swise@...ngridcomputing.com, rdreier@...co.com, daisyc@...ibm.com,
wenxiong@...ibm.com, bhua@...ibm.com, divy@...lsio.com,
dm@...lsio.com, 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
Karen Xie wrote:
> Cxgb3i iSCSI driver
>
> Signed-off-by: Karen Xie <kxie@...lsio.com>
> ---
>
> drivers/scsi/cxgb3i/Kconfig | 6
> drivers/scsi/cxgb3i/Makefile | 5
> drivers/scsi/cxgb3i/cxgb3i.h | 155 +++
> drivers/scsi/cxgb3i/cxgb3i_init.c | 109 ++
> drivers/scsi/cxgb3i/cxgb3i_iscsi.c | 800 ++++++++++++++
> drivers/scsi/cxgb3i/cxgb3i_offload.c | 2001 ++++++++++++++++++++++++++++++++++
> drivers/scsi/cxgb3i/cxgb3i_offload.h | 242 ++++
> drivers/scsi/cxgb3i/cxgb3i_ulp2.c | 692 ++++++++++++
> drivers/scsi/cxgb3i/cxgb3i_ulp2.h | 106 ++
> 9 files changed, 4116 insertions(+), 0 deletions(-)
> create mode 100644 drivers/scsi/cxgb3i/Kconfig
> create mode 100644 drivers/scsi/cxgb3i/Makefile
> create mode 100644 drivers/scsi/cxgb3i/cxgb3i.h
> create mode 100644 drivers/scsi/cxgb3i/cxgb3i_init.c
> create mode 100644 drivers/scsi/cxgb3i/cxgb3i_iscsi.c
> create mode 100644 drivers/scsi/cxgb3i/cxgb3i_offload.c
> create mode 100644 drivers/scsi/cxgb3i/cxgb3i_offload.h
> create mode 100644 drivers/scsi/cxgb3i/cxgb3i_ulp2.c
> create mode 100644 drivers/scsi/cxgb3i/cxgb3i_ulp2.h
Comments:
* SCSI drivers should be submitted via the linux-scsi@...r.kernel.org
mailing list.
* The driver is clean and readable, well done
* 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.
So, additional information on your TCP port usage would be greatly
appreciated. Also, how does this interact with IPv6? Clearly it
interacts with IPv4...
Jeff
--
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
Powered by blists - more mailing lists