[ofiwg] [libfabric-users] feature requests

[Hefty, Sean]

> The key here is: don't try to amalgamate and have "super" network
> addresses.  Just use any given network address to identify the remote
> *machine*, and then start going through the mechanics of dealing with
> multiple network addresses.

I was thinking of the case where a single OFI 'multi-rail' endpoint maps to multiple underlying 'single-rail' endpoints.  In that case, the multi-rail EP address can be anything that's convenient, including the union-address concept.  So, for example, if the app calls getname(), then exchanges that out of band, we've automatically conveyed all usable addresses to the peer.

For apps that don't care how many underlying EPs are used, or what their addresses are, this would work fine.  For apps that do want control over the underlying EPs, this provides that as well.  If we consider large scale fabrics, the ability to select specific network address and/or port ranges may be important.

Plus, I think such a concept would be easy to implement, which is my real objective.  :)  The app may just need to deal with huge addresses. 

Along these lines, I wonder if adding some sort of filter on the domain is needed, or allowing the domain_name to contain a list.

- Sean