[ofiwg] wait sets

Ben Turrubiates (bturrubi) bturrubi at cisco.com
Wed Feb 3 23:59:36 PST 2016


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" <sean.hefty at intel.com> 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.



More information about the ofiwg mailing list