On Wed, Oct 21, 2009 at 11:49:52PM -0700, Sean Hefty wrote: > > This is actually something of a mandatory notion to implement the > > full generality of the IB CM protocol which allows the CM REP to > > contain a port GUID of another port on the same node (multi-port > > APM is an IB feature). So you never know what port the accept() > > result will get bound to. > > You can redirect (REJ) a REQ to a different port, but you can't accept (REP) a > connection on a different port.
Do you have a compliance statment for that? :) Spec says: The initiator is responsible for proposing the Port Addresses (Primary and optional Alternate) that the target (REQ recipient) is to use for the channel. Based on the path defined by those port addresses, the initiator provides timeout information and the Service Level to be used by the target for any messages that it initiates. The SL from initiator to target need not be the same as from target to initiator, but the SL that is contained within the REQ message is the one that the initiator would prefer the target use. Path in- formation is available from Subnet Administration (see section 15.2.5.16 PathRecord). 'Proposing the Port Addresses' == Any Port On the Node, IMHO. Someone went to alot of trouble to include enough unnecessary information to make that possible, and it is necessary for multi port APM. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
