[ofiwg] wait sets

[Hefty, Sean]

> >>>    1. If it is okay to wait
> >> >    1.1.   Wait for one or more events to occur
> >> >    2. Get list of queues ready for action
> >> >    3. Process each queue
> >> >
> >> > We then define step 1.  Ba-da-bing, ba-da-boom, and we're done.
> >>
> >> Yes, this seems to help some.
> >
> >To answer Ben's question from his email, I believe that trywait is needed
> >as the wait objects may be independent from the queues.  It doesn't just
> >check if a wait can proceed, but must also prepare for it.  For example,
> >by clearing out old events.
> 
> ’m still not sure I understand the concept of ‘readiness’ in this
> situation. When we talk about ‘edge triggered’ and ‘level triggered’ are
> we using the same definitions as the epoll man page? If so, then does this
> preparation step apply to both level and edge triggered interfaces? Also,
> why should wait objects be edge triggered? It seems counter-intuitive. Is
> it for performance reasons?

With trywait, I don't think we need to define this.  Trywait just needs to avoid application spinning when there is no work to do (queues are empty), and infinite waiting when work is available (queues are not empty).


> >Trywait would need to be introduced, for example:
> >
> >    1. if fi_trywait == 0
> >    1.1.   poll/select
> >    2. fi_poll
> >    3. fi_cq_read/fi_eq_read/fi_cntr_read
> 
> So for API calls the reset happens at the end of fi_wait/_sread, but for
> OS calls it happens at the beginning of fi_trywait?

For fi_wait/sread, the reset likely happens sometime before the wait occurs internally.  For OS calls, it happens inside trywait.  The location of the reset inside those calls is implementation specific.