[lkml]   [2008]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator

> Hi Jeff,
> Mike Christie will not merge this code until he has an explicit
> acknowledgement from netdev.
> As you mentioned, the port stealing approach we've taken has its issues.
> We consequently analyzed your suggestion to use a different IP/MAC address for
> iSCSI and it raises other tough issues (separate ARP and DHCP management,
> unavailability of common networking tools).
> On these grounds, we believe our current approach is the most tolerable.
> Would the stack provide a TCP port allocation service, we'd be glad to use it
> to solve the current concerns.
> The cxgb3i driver is up and running here, its merge is pending our decision.
> Cheers,
> Divy
Hey Dave/Jeff,

I think we need some guidance here on how to proceed. Is the approach
currently being reviewed ACKable? Or is it DOA? If its DOA, then what
approach do you recommend? I believe Jeff's opinion is a separate
ipaddr. But Dave, what do you think? Lets get some agreement on a high
level design here.

Possible solutions seen to date include:

1) reserving a socket to allocate the port. This has been NAK'd in the
past and I assume is still a no go.

2) creating a 4-tuple allocation service so the host stack, the rdma
stack, and the iscsi stack can share the same TCP 4-tuple space. This
also has been NAK'd in the past and I assume is still a no go.

3) the iscsi device allocates its own local ephemeral posts (port
stealing) and use the host's ip address for the iscsi offload device.
This is the current proposal and you can review the thread for the pros
and cons. IMO it is the least objectionable (and I think we really
should be doing #2).

4) the iscsi device will manage its own ip address thus ensuring 4-tuple

Unless you all want to re-open considering #1 or #2, then we're left
with 3 or 4. Which one?


 \ /
  Last update: 2008-08-08 20:11    [W:0.091 / U:2.100 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site