Or Gerlitz wrote: >> For peer to peer, tracking the QP would still only need to be done on >> the passive side, so that justification can be ignored. This means >> that we are tracking local QPN as part of timewait. > > Sorry, i don't fully follow. > > I was thinking that in the peer to peer connection establishment model, > the passive side is not known beforehand, that is both sides do listen > and send the REQ, one side (CM) becomes the "passive" and the other > becomes the "active", this means you can't tell before getting the REQ > if you would be passive or active so you might ment to say that the code > that places the local qpn in the rbtree can be executed once getting the > REQ and not before sending REQ or REP as done today?
After thinking about peer to peer more, I think that it could insert the local QPN after the passive side calls ib_send_cm_rep(), similar to what's done in the client-server model. If we only want to track local QPNs for the purposes of handling the COMM_EST event, then tracking on the passive side is sufficient. If we want to track local QPNs as part of timewait, then we want tracking on both sides. I went the latter route. - Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
