[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)?
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
>> >as the wait objects may be independent from the queues. It doesn't
>> >check if a wait can proceed, but must also prepare for it. For
>> >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
>> preparation step apply to both level and edge triggered interfaces?
>> why should wait objects be edge triggered? It seems counter-intuitive.
>> 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
>> >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