> Basically, I wasn't referring to such new verbs as vendor extensions, > but rather as new verbs we want to add at this and/or future points of > time which didn't exist at the time the IB stack and specifically its > kernel/user ABIs/APIs were written (couple of years ago...).
To be clear, there are 2 sides to ibverbs - the app side, and the provider library. On the app side, new functionality would be added directly to libibverbs. I would reuse what's there if possible, and provide direct API calls where needed. For example, the xrc patch adds: ibv_create_xsrq() ibv_open_xrcd() ibv_close_xrcd() as new APIs. On the provider side, the necessary calls are obtained by ibverbs calling get_ext_ops(). I haven't come up with another way of extended verbs that would be as easy for an application to use, given that most of the calls and data structures are reusable. - Sean -- 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
