2008-07-31 01:26:25

by Karen Xie

[permalink] [raw]
Subject: RE: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator

>Comments:
>
>* SCSI drivers should be submitted via the [email protected]
>mailing list.

Will do that. Thanks.

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

The collisions between the host stack and iSCSI offload are unlikely
because the iSCSI target server's port is unique (nailed down as 3260).
If an offload card is plugged in, all iSCSI connections to a given
target (i.e., destination/port) are offloaded. There is precedence for
this approach such as RDMA/iWarp.

>
>So, additional information on your TCP port usage would be greatly
>appreciated. Also, how does this interact with IPv6? Clearly it
>interacts with IPv4...

Currently, IPv6 connection request will not be honored, I will make sure
the checking is added in the resubmission.


2008-07-31 12:46:51

by Boaz Harrosh

[permalink] [raw]
Subject: Re: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator

Karen Xie wrote:
>> Comments:
>>
>> * SCSI drivers should be submitted via the [email protected]
>> mailing list.
>
> Will do that. Thanks.
>
>> * 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.
>
> The collisions between the host stack and iSCSI offload are unlikely
> because the iSCSI target server's port is unique (nailed down as 3260).
> If an offload card is plugged in, all iSCSI connections to a given
> target (i.e., destination/port) are offloaded. There is precedence for
> this approach such as RDMA/iWarp.
>

Please note that all SW iscsi targets I know, let you change the default
3260 port to whatever you want. Is that supported?

Jeff is there a way for the user-mode demon to reserve the port beforehand
so it will appear to be taken.

>> So, additional information on your TCP port usage would be greatly
>> appreciated. Also, how does this interact with IPv6? Clearly it
>> interacts with IPv4...
>
> Currently, IPv6 connection request will not be honored, I will make sure
> the checking is added in the resubmission.
>
>
Boaz