All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Wise <swise@opengridcomputing.com>
To: "Kanevsky, Arkady" <Arkady.Kanevsky@netapp.com>
Cc: Sean Hefty <sean.hefty@intel.com>,
	Sean Hefty <mshefty@ichips.intel.com>,
	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.
Date: Fri, 28 Sep 2007 14:46:55 -0500	[thread overview]
Message-ID: <46FD5A2F.7010409@opengridcomputing.com> (raw)
In-Reply-To: <C98692FD98048C41885E0B0FACD9DFB80518755A@exnane01.hq.netapp.com>



Kanevsky, Arkady wrote:
> 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
> 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.
> This way, ULP "connection manager" handles RDMA-ness under the covers,
> 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.



> 
> 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: 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.
>>
>>> What is the model on how client connects, say for iSCSI, when client 
>>> and server both support, iWARP and 10GbE or 1GbE, and would like to 
>>> setup "most" performant "connection" for ULP?
>> For the "most" performance connection, the ULP would use IB, 
>> and all these problems go away.  :)
>>
>> This proposal is for each iwarp interface to have its own IP 
>> address.  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 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
>>

  reply	other threads:[~2007-09-28 19:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-23 20:36 [PATCH v3] iw_cxgb3: Support "iwarp-only" interfaces to avoid 4-tuple conflicts Steve Wise
2007-09-23 20:36 ` [ofa-general] " Steve Wise
2007-09-26 19:02 ` Steve Wise
2007-09-27 18:38 ` Sean Hefty
2007-09-27 18:56   ` [ofa-general] [PATCH v3] iw_cxgb3: Support "iwarp-only" interfacesto " Kanevsky, Arkady
2007-09-27 18:56     ` Kanevsky, Arkady
2007-09-27 19:11     ` [ofa-general] [PATCH v3] iw_cxgb3: Support "iwarp-only"interfacesto " Sean Hefty
2007-09-27 20:19       ` [ofa-general] [PATCH v3] iw_cxgb3: Support"iwarp-only"interfacesto " Kanevsky, Arkady
2007-09-27 20:19         ` Kanevsky, Arkady
2007-09-28 19:46         ` Steve Wise [this message]
2007-09-28 20:36           ` Kanevsky, Arkady
2007-09-28 20:36             ` Kanevsky, Arkady
2007-09-28 21:27             ` Steve Wise
2007-09-28 21:34             ` Sean Hefty
2007-10-01 12:34               ` [ofa-general] [PATCH v3] iw_cxgb3: Support"iwarp-only"interfacestoavoid " Kanevsky, Arkady
2007-10-01 12:34                 ` Kanevsky, Arkady
2007-10-08 18:03         ` [ofa-general] [PATCH v3] iw_cxgb3: Support"iwarp-only"interfacesto avoid " Steve Wise
2007-10-08 18:03           ` Steve Wise
2007-09-27 19:25   ` [ofa-general] [PATCH v3] iw_cxgb3: Support "iwarp-only" interfaces to " Steve Wise
2007-09-27 20:14     ` Sean Hefty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46FD5A2F.7010409@opengridcomputing.com \
    --to=swise@opengridcomputing.com \
    --cc=Arkady.Kanevsky@netapp.com \
    --cc=general@lists.openfabrics.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mshefty@ichips.intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=rdreier@cisco.com \
    --cc=sean.hefty@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.