>> 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? :)
The REP doesn't carry port (i.e. GID) information. >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. Under reject reasons: 12 Primary Remote Port GID rejected The recipient of the REQ message could not (or would not) accept the Primary Remote Port GID GID of acceptable port. 13 Primary Remote Port LID rejected The recipient of the REQ message could not (or would not) accept the Primary Remote Port LID LID of acceptable port. I interpret this as the REQ carries the proposal. If the passive side aggress with the proposal, it accepts the connection, otherwise it rejects. - Sean -- 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
