[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