Re: [PATCH] link-local address fix for rdma_resolve_addr

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Thu, Oct 22, 2009 at 10:59:37AM -0700, Sean Hefty wrote:
> >> 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.

Why would it need to? The REQ contains all the port information
necessary, the active side doesn't get to pick the port, it just gets
to approve it.

> 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.

I agree.

But the proposal contains a complete description of the data carrying
port (GUID, GID, LID) and there is *nothing* in the spec that says
that description must match the port the GMP is received on.

Don't get confused by GMP redirection, that is yet again something
else :)

So, IBA allows the active side to propose a data connection with
primary path on Port 1, alternate path on Port 2 and send the GMP on
Port 2.

The passive CM then looks at this and decides if it is within local
policy constraints, if not it returns 12 or 13.

Thus, you cannot know what port the data QP will be bound to until you
process the REQ - just like IP.

Jason
--
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