Thread (9 messages) flat view 9 messages, 4 authors, 2016-06-16

Re: [v5, 1/2] cxl: Add mechanism for delivering AFU driver specific events

From: Vaibhav Jain <hidden>
Date: 2016-05-25 07:23:07

Hi Matt,

"Matthew R. Ochs" [off-list ref] writes:
The purpose for the count is so the AFU driver is only called when it
has something to send. Otherwise we don't want to be called.
Agreed, but this opens up a possible boundary condition where in we have
non-zero event count and deliver_event callback returns a NULL/empty
struct (This isn't handled correctly at the moment). Imo the condition
event-count == number-of-calls-to-deliver_events is bit too rigid.

Instead a more relaxed condition can be number-of-calls-to-deliver_event ==
count-until-deliver_event-returns-NULL. This could be implemented as
boolean flag inside the context to indicate that afu-driver has some
events queued. This flag can be set when cxl_context_events_pending gets
called. The cxl code can simply call deliver_event on each read call
untill it returns NULL in which case this boolean flag is reset.

This should slightly simplify the code flow at the afu-driver end as
enquing to an event need not be paired by a call to
cxl_context_events_pending. It can quite possibly enqueue bunch of
events and then do a single call to cxl_context_events_pending. In this
case the function cxl_context_events_pending essentially works more like
a function named as cxl_context_events_flush.

~ Vaibhav
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help