[ofiwg] Agenda topics for tomorrow's OFI WG call

[Paul Grun]

Please send along suggestions for agenda items for tomorrow's OFI WG call.  Here are two topics that Sean suggested.
Regards,
-Paul

-----Original Message-----
From: Hefty, Sean [mailto:sean.hefty at intel.com] 
Sent: Saturday, July 11, 2015 11:22 PM
To: Paul Grun
Subject: Next OFIWG call

I'm not sure what agenda items you have planned for the next ofiwg, but here are a couple of topics that I think are worth discussing.

There is an open question on how to have fabtests handle different revisions of libfabric.  The general questions are:

Should fabtests simply remain in sync with the latest version of libfabric?
+: Reduces maintenance costs.
-: Testing that libfabric is backwards compatible requires using older versions of fabtests.

Should the latest version of fabtests support all previous versions of libfabric?
+: Makes it easier to test for backwards compatibility
-: Greatly increases maintenance costs.
+: Provides an example of how an app can support multiple libfabric versions

These are the two extremes, and some middle ground could be targeted instead.  For example, selecting whether or not to be backwards compatible on a feature by feature basis.

I would like to get a feel from the community on this.  Though, ultimately, the decision may still come down to whoever is doing the work to handle the maintenance.

--

There is also an open issue regarding completion flags (#1142).  When a data operation completes, we can report information about the type of request that it was for.  E.g. was it a transmit or receive operation?  This can be extended, for example, was the transmit a send or RMA write?  Did it have remote CQ data (immediate data)?  Etc. up to capture the full amount of information about the request.  The question is what amount of information are apps actually needing?

I've currently defined completion flags which can map well to something like an opcode.  The more this can be relaxed, the more optimization possibilities there are.

- Sean