> From: linux-rdma-owner@xxxxxxxxxxxxxxx [mailto:linux-rdma- > owner@xxxxxxxxxxxxxxx] On Behalf Of Hefty, Sean > Sent: Monday, November 20, 2017 8:59 PM > To: Kalderon, Michal <Michal.Kalderon@xxxxxxxxxx>; Jason Gunthorpe > <jgg@xxxxxxxx>; linux-rdma@xxxxxxxxxxxxxxx > Cc: Elior, Ariel <Ariel.Elior@xxxxxxxxxx>; Amrani, Ram > <Ram.Amrani@xxxxxxxxxx>; Radzi, Amit <Amit.Radzi@xxxxxxxxxx> > Subject: RE: rstream application > > > We've been debugging an issue with the rstream application, would be > > glad to get your help. > > This application is part of the OFA logo program and therefore we've > > been debugging it. > > Intermittently we get an error: Connection refused (stale connection ) > > on the second connect in the test. > > (rstream -S all -T a ) > > It looks like in some cases the server side gets a new connection > > request before destroying the cm-id, Leaving the remote id and remote > > qp in the remote_id_table and remote_qp_table > > Can you provide more details on when the problem occurs? Is the client > attempting to connect to a server that is not yet active, or trying to connect > to a server that already accepted a connection? Do you know if the > hardware re-uses QPNs? > -- Thanks Sean, Rstream client connects to server, runs latency test, calls rs_close and then connects Again before running the bandwidth test. The issue occurs on the second connect (after latency and before bandwidth). Server does the same. It seems the close state in some cases doesn't complete Before the second connect request arrives. Yes, the hardware re-uses QPNs once they are destroyed. > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the > body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at > http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
