[ofa-general] Re: Re: IPoIB-CM UC mode

[Michael S. Tsirkin]

> Quoting Or Gerlitz <ogerlitz at voltaire.com>:
> Subject: Re: [ofa-general] Re: Re: IPoIB-CM UC mode
> 
> Or Gerlitz wrote:
> >Michael S. Tsirkin wrote:
> 
> >>In the typical case (remote side reboots) both the GID and the UD QPN 
> >>stay the same, so it seems there won't be any neighbour update, right?  
> >>If so, while playing with neighbour update events might get us data path 
> >>speed-up, it will not solve the problem of detecting the connection is 
> >>alive.
> 
> >Second, let me think...

I don't see why are you trying to get rid of keepalives.
With RC we currently have an arbitrary ACK timeout, and this
is no different, and quite easy to implement.

> OK, if IPoIB-CM was using bi-directional connection, problem is solved, 
> since the remote side re-connects (to send the ARP reply) and either the 
> CM or IPoIB-CM the CM consumer invalidates the existing connection.

Why should this invalidate the existing connection?
IMO killing a connection simply because remote connected wouldn't
be spec compliant: spec allows multiple connections to a single
host, and it's easy to imagine a setup where this will be
useful e.g. for performance reasons
(I actually have such a project on my todo list).

> Also with uni-directional connections, when the remote side re-connects 
> to us, it can put in the private data its RX QPN (or 0 if there's no 
> such). The ipoib-cm CM callback can compare this QPN against what it 
> knows on the remote and if its different, re-connect. This can be 
> further simplified, but lets first take it high-level.

What if remote already has a connection to us?
Anyway, this is clearly outside the existing spec.

> Can you remind me what was --the-- reasoning for uni directional 
> connections?

Lots of reasons. Simplicity of implementation. Solution to tricky dead/livelock
scenarios with crossing connection requests.  Fault containment.  Ability to
extend to multiple connections per host in the future.

It just looks like a good idea.

-- 
MST