Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > Subject: Re: [openib-general] Re: CMA stuff > > Michael S. Tsirkin wrote: > >- Do we expect ULPs to let CMA mange the QPs, or do it themselves? > > The CMA manages the QP states only if the user calls rdma_create_qp(). If > this call is not made, the user must perform QP state transitions > themselves. In general, I would expect most users to call > rdma_create_qp(). The option is there mainly to support userspace QPs. > > >- When cma manages QP state, there doesnt seem to exist an option > > to post receive WQEs when qp is in INIT state. > > This is required at least for SDP if SDP's to use. > > The QP is in the INIT state after rdma_create_qp() is called. Receives may > be posted at that time.
I'm talking about the passive side. > >- CMA does not seem to do anything with the path static rate it gets > > from SA. Am I missing the place where it does do it? > > What are you wanting it to do with it? It's possible that what you're > looking for is done by the IB CM. Pass it to QP in an ah? > Backlog doesn't make much sense when the CMA is used over the IB CM, since > it's a direct callback model. I looked at adding backlog as a parameter to > the IB CM, but couldn't come up with a decent implementation for what to do > with it. The uCMA is the only location where any queuing of requests is > actually done. We could just continue with setup and then close the connection if backlog is exceeded. > > - It seems that in ucma backlog is checked when a connection request > > arrives. However this is not how TCP handles backlog, > > so socket apps being ported to CMA might hit a problem. > ... > I think that I need a specific example (i.e. a patch) to see how you would > treat backlog differently. I'm still trying to get my head about the cma implementation, but I'll see what I can do. My idea was to have 2 counters: one counting connections that are being established, gong up to tcp_max_syn_backlog, and another one after the connection is established, up to local socket backlog. -- Michael S. Tsirkin Staff Engineer, Mellanox Technologies _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
