On 9/21/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
And how does a completion vector relate to callbacks? Would this
be typically identifying the number of "processing resources" (such
as distinct execution contexts) that will be allocated?
Or more formally, if two CQs use the same completion vector, are
we guaranteed that they will not have concurrent callbacks?
How would this enable kernel mode processing of notifications
for a user-mode CQ by the proxy?
Caitlin> I'm not sure I follow what a "completion channel" is. My
Caitlin> understanding is that work completions are stored in
Caitlin> user-accessible memory (typically a ring buffer). This
Caitlin> enables fast-path reaping of work completions. The OS has
Caitlin> no involvement unless notifications are enabled.
Right. Notifications ("events" in the terminology I used) are the
only thing I was talking about.
Caitlin> The "completion vector" is used to report completion
Caitlin> notifications. So is the completion vector a *single*
Caitlin> resource used by the driver/verbs to report completions,
Caitlin> where said notifications are then split into user context
Caitlin> dependent "completion channels"?
Yes.
And how does a completion vector relate to callbacks? Would this
be typically identifying the number of "processing resources" (such
as distinct execution contexts) that will be allocated?
Or more formally, if two CQs use the same completion vector, are
we guaranteed that they will not have concurrent callbacks?
Caitlin> The RDMAC verbs did not define callbacks to userspace at
Caitlin> all. Instead it is assumed that the proxy for user mode
Caitlin> services will receive the callbacks, and how it relays
Caitlin> those notifications to userspace is outside the scope of
Caitlin> the verbs.
That "outside the scope" part is exactly what I'm talking about
implementing here.
How would this enable kernel mode processing of notifications
for a user-mode CQ by the proxy?
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
