Jason Gunthorpe wrote: > Walukiewicz, Miroslaw wrote: >> called for many QPs, there is a single entry point to >> ib_uverbs_post_send using write to /dev/infiniband/uverbsX. In that >> case there is a lookup to QP store (idr_read_qp) necessary to find a >> correct ibv_qp Structure, what is a big time consumer on the path.
> I don't think this should be such a big problem. The simplest solution > would be to front the idr_read_qp with a small learning hashing table. yes, there must be a few ways (e.g as Jason suggested) to do this house-keeping much more efficient, in a manner that fits fast path - which maybe wasn't the mindset when this code was written as its primary use was to invoke control plane commands. >> The NES IMA kernel path also has such QP lookup but the QP number >> format is designed to make such lookup very quickly. The QP numbers in >> OFED are not defined so generic lookup functions like idr_read_qp() must be >> use. > Maybe look at moving the QPN to ibv_qp translation into the driver > then - or better yet, move allocation out of the driver, if Mellanox > could change their FW.. You are right that we could do this much > faster if the QPN was structured in some way I think there should be some validation on the uverbs level, as the caller is untrusted user space application, e.g in a similar way for each system call done on a file-descriptor Or. Or. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
