[openib-general] [CMA] blocking in rdma_listen()
Does anyone have any objection to rdma_listen() blocking? I'm working on adding support for listening across any device, but need to synchronize with device addition/removal. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [CMA] blocking in rdma_listen()
On Tue, 11 Oct 2005, Sean Hefty wrote: Does anyone have any objection to rdma_listen() blocking? I'm working on adding support for listening across any device, but need to synchronize with device addition/removal. I have a strong objection to making it block. Our goal is to provide an interface with semantics similar to the sockets interface. A socket's listen function does not block (e.g. inet_listen). Since not blocking is what ULPs expect, kDAPL's listen function does not block. The same should be true of the CMA function. james ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [CMA] blocking in rdma_listen()
James Lentini wrote: Our goal is to provide an interface with semantics similar to the sockets interface. A socket's listen function does not block (e.g. inet_listen). Since not blocking is what ULPs expect, kDAPL's listen function does not block. The same should be true of the CMA function. From what I can see, kDAPL connect and listen calls can block, as does inet_listen. I'm referring to the thread blocking within the call, specifically on a semaphore and memory allocation using GFP_KERNEL. I am not referring to listen blocking until a connection request is received. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [CMA] blocking in rdma_listen()
On Tue, 11 Oct 2005, Sean Hefty wrote: James Lentini wrote: Our goal is to provide an interface with semantics similar to the sockets interface. A socket's listen function does not block (e.g. inet_listen). Since not blocking is what ULPs expect, kDAPL's listen function does not block. The same should be true of the CMA function. From what I can see, kDAPL connect and listen calls can block, as does inet_listen. I'm referring to the thread blocking within the call, specifically on a semaphore and memory allocation using GFP_KERNEL. I am not referring to listen blocking until a connection request is received. I thought you meant blocking for a connection request to arrive. Your right the kDAPL and inet_listen functions can block for the reasons you list. I'm ok with rdma_listen() also blocking for these reasons. james ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
