[ofiwg] Agenda for 4/23 OFIWG meeting

[Hefty, Sean]

> Begin a discussion of Traffic Classification mechanisms for libfabric.  We can
> use the attached slide deck to begin.

Here are some thoughts I came up with after the meeting for discussion purposes.
 
* For labels, we can consider higher-level, application centric classes.  Examples would be: storage (or maybe traditional storage), NVM storage, IPC, fabric management, fabric statistics, multi-media, distributed database, etc.

* Application labels could be used in conjunction with the proposed (behavior? semantic?) classes.  Example: a storage label could have the same value as the bulk data label.  We might be able to map these to DSCP values?

* We'll need to decide if labels work best as enums or flags.  This will depend on how high/low the behavior is being defined. 

* We'll eventually need to decide which objects the traffic classes apply to.  Endpoint is one option we discussed.  Transmit context is similar, but allows scalable endpoints to have different classes per context.  Assigning a class per address vector is an alternative approach.  All endpoints using the same AV would use the same traffic class.  (I can envision a fabric where this might be required).  Along this line, the class might be specified per destination, which maps to a class per fi_addr_t.

* We may need a mechanism for a provider to indicate restrictions in how classes may be assigned.  E.g. see FI_MR_ENDPOINT, which restricts MRs to endpoints rather than the default of per domain.

I have a weak preference for the following options:

* Semantic defined classes
* Associate traffic classes per destination (fi_addr_t)
* If needed, expose provider restriction of one class per source address (fi_ep)

- Sean