From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Wise Subject: Re: [PATCH v2] RDMA/CMA: fix iWARP adapter TCP port space usage Date: Wed, 07 Jul 2010 11:12:28 -0700 Message-ID: <4C34C38C.5060803@opengridcomputing.com> References: <4C34AAA6.2080909@opengridcomputing.com> <2EFBCAEF10980645BBCFB605689E08E904928DA373@azsmsx506.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <2EFBCAEF10980645BBCFB605689E08E904928DA373-uLM7Qlg6MbdZtRGVdHMbwrfspsVTdybXVpNB7YpNyf8@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "Tung, Chien Tin" Cc: Bernard Metzler , Jason Gunthorpe , "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "Waskiewicz Jr, Peter P" , Roland Dreier List-Id: linux-rdma@vger.kernel.org Tung, Chien Tin wrote: >> But the IB and IW port space is _already_ merged by the RDMA_CM. That's >> my point. So a solution that breaks this impacts transport-independent >> applications that use the rdma cm... >> >> >>> Could we prove a strong need for that short-cut? >>> If its really needed, one global RDMA_CM instance should be able >>> to achive that requirement. But wouldn't that go together with a waste >>> of unused transports resources (i.e., IB binds would create >>> and bind also TCP sockets..?). >>> >>> >> My comment has nothing to do with TCP ports but rather RDMA ports as >> abstracted by the RDMA_CM. The RDMA_PS_TCP port space is shared among >> all the RDMA transports. So if you rdma_bind() to port space >> RDMA_PS_TCP, addr INADDR_ANY, port 9999, then it will bind the cm_id to >> all IB and IW providers for that address/port (note the providers don't >> really get called until rdma_listen()). Thus if you propose moving the >> bind operation down into the device providers, then the IB providers >> will also have to add this logic. Or some solution must be defined to >> keep the IB and IW port spaces common. Otherwise the RDMA_CM cannot >> support transport independent applications... >> > > I didn't think about this before, a bit too focused on solving the iWARP side. > Bernard, what about letting RDMA CM allocate the socket and exposing it to > softiWARP? > > We don't want the RDMA CM allocating sockets. That won't fly upstream eh? Unless we have a provider attribute or something that tells the RDMA CM that this provider uses a host socket. And this might really need to go into the IWCM... -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html