[ofiwg] Agenda for 4/23 OFIWG meeting

[Paul Grun]

One thought to consider is the idea of an 'inheritance model'.  The idea is that a traffic class can be assigned to a domain, an endpoint, or a transmit context. In the libfabric object hierarchy, domains encompass endpoints and endpoints encompass transmit contexts.  The idea of inheritance is that if a traffic class isn't defined for a specific object, that object inherits the classification from the object above it. 
-Paul

>-----Original Message-----
>From: Hefty, Sean <sean.hefty at intel.com>
>Sent: Wednesday, April 24, 2019 10:36 AM
>To: Paul Grun <grun at cray.com>; 'ofiwg at lists.openfabrics.org'
><ofiwg at lists.openfabrics.org>
>Subject: RE: Agenda for 4/23 OFIWG meeting
>
>> 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