> Quoting Or Gerlitz <[EMAIL PROTECTED]>: > 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 _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
