[ofiwg] async fi_av_insert
Hefty, Sean
sean.hefty at intel.com
Mon Oct 20 17:07:37 PDT 2014
> Fi_av_insert() and friends are defined to proceed asynchronously when an
> EQ is bound to the AV, but it's not clear how the caller should map the
> completions back to the original insert request. I suppose the fi_addr
> structure pointer passed in could be returned in the "context" field, but
> that constrains the use a little. Shall we go with that for now? If this
> proves unworkable in a real-world use case then we could add
> "fi_av_insert_context" when an array of context values are passed in, to
> be returned in the associated EQ with each insert completion?
See issue #191. The insert calls should accept a void *context parameter as input.
> Another thing - address resolution can complete "unsuccessfully" but non-
> fatally. For example, if you try to find a route to a particular IP/port,
> that may fail with something like "host unreachable" but that is not an
> error in the underlying address resolution system. Hence, av_insert
> requests need to have a "status" field in their completion struct. I can
> see other completion types having this requirement, should we add "int
> status" to fi_eq_entry ? Or let av_insert have its own completion struct
> with a status field?
The intent is for asynchronous AV insertion errors (or any asynchronous control operation errors) to be reported using fi_eq_err_entry. Successful entries would be fi_eq_event.
> If we extend fi_eq_entry, event will be "FI_COMPLETE", status will be
> insert completion/failure, fid will be the AV on which the insert was
> done, and context will be the fi_addr speficied in av_insert call.
FI_COMPLETE is intended as a successful event status. But, the fi_eq_err_entry/fi_eq_event fid and context would be as you describe.
More information about the ofiwg
mailing list