RE: [ofa-general] [PATCH v3] iw_cxgb3: Support"iwarp-only"interfacesto avoid 4-tuple conflicts.

Exactly,
it forces the burden on administrator.
And one will be forced to try one mount for iWARP and it does not
work issue another one TCP or UDP if it fails.
Yack!

And server will need to listen on different IP address and simple
* will not work since it will need to listen in two different domains.

Had we run this proposal by administrators?
Thanks,

Arkady Kanevsky                       email: arkady@netapp.com
Network Appliance Inc.               phone: 781-768-5395
1601 Trapelo Rd. - Suite 16.        Fax: 781-895-1195
Waltham, MA 02451                   central phone: 781-768-5300
 

-----Original Message-----
From: Steve Wise [mailto:swise@opengridcomputing.com] 
Sent: Friday, September 28, 2007 3:47 PM
To: Kanevsky, Arkady
Cc: Sean Hefty; Sean Hefty; netdev@vger.kernel.org; 
rdreier@cisco.com; linux-kernel@vger.kernel.org; 
general@lists.openfabrics.org
Subject: Re: [ofa-general] [PATCH v3] iw_cxgb3: 
Support"iwarp-only"interfacesto avoid 4-tuple conflicts.



Kanevsky, Arkady wrote:

quoted

Sean,
IB aside,
it looks like an ULP which is capable of being both RDMA aware and 
RDMA not-aware, like iSER and iSCSI, NFS-RDMA and NFS, SDP and 
sockets, will be treated as two separete ULPs.
Each has its own IP address, since there is a different IP 

address for 

quoted

iWARP port and "regular" Ethernet port. So it falls on the users of 
ULPs to "handle" it via DNS or some other services.
Is this "acceptable" to users? I doubt it.

Recall that ULPs are going in opposite directions by having a 
different port number for RDMA aware and RDMA unaware 

versions of the ULP.

quoted

This way, ULP "connection manager" handles RDMA-ness under 

the covers, 

quoted

while users plug an IP address for a server to connect to.
Thanks,

Arkady, I'm confused about how this proposed design changes 
the behavior of the ULPs that run on TCP and iWARP.  I don't 
see much difference from the point of view of the ULPs.

The NFS-RDMA server, for example, will not need to change 
since it binds to address 0.0.0.0 which will translate into a 
bind/listen on the specific iwarp address for each iwarp 
device on the rdma side, and address 0.0.0.0 for the TCP side.

Am I missing your point?

The real pain, IMO, with this solution is that it FORCES the 
admins to use 2 subnets when 1 is sufficient if the net 
maintainers would unify the port space...

Steve.

quoted

Arkady Kanevsky                       email: arkady@netapp.com
Network Appliance Inc.               phone: 781-768-5395
1601 Trapelo Rd. - Suite 16.        Fax: 781-895-1195
Waltham, MA 02451                   central phone: 781-768-5300
 

quoted

-----Original Message-----
From: Sean Hefty [mailto:sean.hefty@intel.com]
Sent: Thursday, September 27, 2007 3:12 PM
To: Kanevsky, Arkady; Sean Hefty; Steve Wise
Cc: netdev@vger.kernel.org; rdreier@cisco.com; 
linux-kernel@vger.kernel.org; general@lists.openfabrics.org
Subject: RE: [ofa-general] [PATCH v3] iw_cxgb3: 
Support"iwarp-only"interfacesto avoid 4-tuple conflicts.

quoted

What is the model on how client connects, say for iSCSI, 

when client 

quoted

quoted

quoted

and server both support, iWARP and 10GbE or 1GbE, and 

would like to 

quoted

quoted

quoted

setup "most" performant "connection" for ULP?

For the "most" performance connection, the ULP would use 

IB, and all 

quoted

quoted

these problems go away.  :)

This proposal is for each iwarp interface to have its own 

IP address.  

quoted

quoted

Clients would need an iwarp usable address of the server and would 
connect using rdma_connect().  If that call (or 
rdma_resolve_addr/route) fails, the client could try 

connecting using 

quoted

quoted

sockets, aoi, or some other interface.  I don't see that Steve's 
proposal changes anything from the client's perspective.

- Sean
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-general