[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1828884A29C6694DAF28B7E6B8A8237368B9A40F@ORSMSX101.amr.corp.intel.com>
Date: Wed, 13 Feb 2013 17:44:58 +0000
From: "Hefty, Sean" <sean.hefty@...el.com>
To: Or Gerlitz <ogerlitz@...lanox.com>
CC: "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH v4 4/9] rdma/cm: Update port reservation to support AF_IB
> > The AF_IB uses a 64-bit service id (SID), which the
> > user can control through the use of a mask. The rdma_cm
> > will assign values to the unmasked portions of the SID
> > based on the selected port space and port number.
>
> Something here I am not sure to follow -- if AF_IB consumers are allowed
> to provide 64-bit SID, how
> the IB port space is expressed in their SIDs?
The spec, notably the RDMA CM Annex, provides fixed values for the upper 48-bits of the service ID. Only the lower 16-bits are available to users. The upper bits end up identifying the various 'port spaces'.
(Note that there's no actual association between an IB port space and port spaces in the IP network stack.)
> Wouldn't it make sense to use a simpler approach that has a dedicated
> IB_PS in the port space
> portion of the RDMA-CM IP IBTA annex and let the consumer provide 16
> bits for their part of the SID?
Ultimately, IB establishes communication using 64-bit service IDs, which is what sockaddr_ib exposes.
The SID mask was proposed by Jason as a way to simplify things. Conceptually, AF_IB has a single port space range, the 64-bit SID. The mask helps us break the SID into the various ranges, so we can clearly know which parts of the SID are fixed, and which can be variable. E.g. when connecting, the entire SID must be provided. However, when binding we want to support binding to a specific SID or only to a SID range (i.e. port space).
(I'm having trouble finding the original email threads where this was discussed.)
- Sean
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists