Alright, I think I agree with this. Will this still require processing all queues attached to a wait object, or is there going to be an interface call added to somehow retrieve information about which queues signaled (if possible)?
- Ben On 2/1/16, 10:02 AM, "Hefty, Sean" <[email protected]> wrote: >> >>> 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. _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
