> >> 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).
I understand there are two sets of objects here. Let's make sure I'm not confusing them.
(1) A collection of user-objects passed via ioctl. This is indicated in the first paragraph.
But as you indicated now we shouldn't support this. So why (apparently) do we?
(2) A collection of user-objects that should be locked for the creation/deletion/modification
of another that was requested via ioctl.
In this case the handler doesn't need to be invoked at all for the collection.
We can easily roll back the "get" phase, if failed during.
We don't expect the "put" phase to fail, if it will fail for some reason. Then this won't really
be handled as the handler was already invoked.
Thanks,
Ram
��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
