On Thu, May 4, 2017 at 5:50 PM, Amrani, Ram <Ram.Amrani@xxxxxxxxxx> wrote: >> The new ioctl based infrastructure either commits or rollbacks >> all objects of the command as one transaction. In order to do >> that, we introduce a notion of dealing with a collection of >> objects that are related to a specific action. >> >> This also requires adding a notion of an action and attribute. >> An action contains a groups of attributes, where each group >> contains several attributes. >> >> When declaring these actions and attributes, we actually declare >> their specifications. When a command is executed, we actually >> allocates some space to hold auxiliary information. >> >> Signed-off-by: Matan Barak <matanb@xxxxxxxxxxxx> >> --- > > Matan, thanks for the RFC! > > If I got this correctly each object will go through three phases - get, handler, and a put. > I don't quite understand how a batch operation, like destroy QPs, can be undone after the handler phase. > I do see it working if at first multiple gets are performed and one of them fails. > In that case undoing is easy because the handlers weren't invoked yet. > > In the case were some user-objects failed the operation how is this reflected upwards? > > Also, I wonder, is there another intention behind batch operations except speed? > It's really not recommended to batch create/destroy. The reason is exactly what you've pointer out. If you batch several "destroy objects" and the n'th one fail, you can't unwind the successful ones. So basically, we want to support a semantic which is similar to what we have today - create a single object or destroy a single object. In this case, the pre-handler stage locks the dependencies of this object (for example, in create_qp you lock the pd and cq so they won't be destroyed) and create the uobject for the QP. The handler itself can assume the requirements it stated in the specifications are filled and just create the QP and tie the uobject to the QP object. In the post-handler stage we commit the QP's uobject and unlock the dependencies (assuming the handler increased the required refcounts). Destroying an object is similar. The only different is that the destruction itself isn't done by the handler, but in the post-handler's code (to share this code between regular "destroy" calls with process tear-down and hardware removal). > > Thanks, > Ram - Matan > -- > 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