lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ