[Lustre-devel] Completion callbacks

Peter Braam Peter.Braam at Sun.COM
Wed Aug 13 15:28:33 PDT 2008

I think it's a requirement that software using the API's is not aware of
this (ie no significant changes in ptlrpc).  As long as the solution is
compatible with that, this looks fine.


On 8/13/08 5:04 AM, "Maxim V. Patlasov" <Maxim.Patlasov at Sun.COM> wrote:

> Folks,
>> Liang Zhen ??:
>>>> 2. we change ptlrpc_master_callback so that: it makes a copy of EV and
>>>> queue it in a
>>>> FIFO and return, another thread process ev's in this FIFO and callback
>>>> one by one and
>>>> we can guarantee events order and call real callbacks without lnet_lock
>> We can even have an eq_callback_thread (or threads pool) in LNet,
>> lnet_enq_event_locked() enqueue event and wakeup the callback_thread,
>> so we don't need change ptlrpc at all.
> I dislike the idea of introducing any additional callback-devoted
> threads because 1) it would spoil the original design of callbacks as
> light-weight notifications and 2) introduce additional latency. I'd
> prefer to see per-MD locks (or per-EQ array of locks, that's quite
> equivalent) to serialize calling callbacks associated with any
> particular MD. This approach looks more natural and "right" than
> inventing callback-threads.
> Sincerely,
> Maxim
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel

More information about the lustre-devel mailing list