Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757063AbXI1VfR (ORCPT ); Fri, 28 Sep 2007 17:35:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753173AbXI1VfB (ORCPT ); Fri, 28 Sep 2007 17:35:01 -0400 Received: from mga06.intel.com ([134.134.136.21]:57694 "EHLO orsmga101.jf.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751567AbXI1VfA (ORCPT ); Fri, 28 Sep 2007 17:35:00 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.21,211,1188802800"; d="scan'208";a="235255200" Message-ID: <46FD7380.6050107@ichips.intel.com> Date: Fri, 28 Sep 2007 14:34:56 -0700 From: Sean Hefty User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Kanevsky, Arkady" CC: Steve Wise , 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. References: <20070923203649.8324.64524.stgit@dell3.ogc.int><46FBF8AF.9040700@ichips.intel.com> <000101c8013a$41b374f0$a7cc180a@amr.corp.intel.com> <46FD5A2F.7010409@opengridcomputing.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1056 Lines: 25 Kanevsky, Arkady wrote: > 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. The server already has to call listen twice. Once for the rdma_cm and once for sockets. Similarly on the client side, connect must be made over rdma_cm or sockets. I really don't see any impact on the application for this approach. We just end up separating the port space based on networking addresses, rather than keeping the problem at the transport level. If you have an alternate approach that will be accepted upstream, feel free to post it. - Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/