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 <[email protected]> >Sent: Wednesday, April 24, 2019 10:36 AM >To: Paul Grun <[email protected]>; '[email protected]' ><[email protected]> >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 _______________________________________________ ofiwg mailing list [email protected] https://lists.openfabrics.org/mailman/listinfo/ofiwg
