See below for notes from the meeting. > I have the following items to bring up for discussion, which may also be > discussed via email. > > * Fabric/domain name resolution service. > Request is to use friendly names to identify a fabric, such as > "primary-ib-subnet"
The option to use a file for mapping names was discussed. However anything defined would be site specific. The decision was made to defer any implementation until a stronger use case emerged. Providers may need to re-examine what they report as their fabric name. The fabric name should be orthogonal from the local interface being used to access it. > * Should libfabric support regular expressions for names? This could make it more difficult when attempting to interact with DNS or other name/address resolution services. Not a strong enough use case has been identified. > * Optimizing unconnected endpoints that communicate with a single peer. > E.g. a 'connected' DGRAM endpoint > How can a provider determine this use case? The general conclusion was to associate an address with the endpoint using some sort of control operation or fi_connect. The latter would require updating the fi_connect parameters and behavior when used with an unconnected endpoint. The intent is that this would allow optimizations by removing the need for the app to specify the destination address with every call, and the provider could avoid lookups, possibly even formatting outbound packets/commands. > * Is there a need to identify loopback only providers, so that apps on > different systems avoid selecting them? Should apps need to opt-in > to seeing loopback providers? There was agreement in the value of indicating loopback support. It turns out that usNIC does not support loopback communication. This results in 3 options: no loopback supported, loopback supported, and loopback only. Today apps must rely on naming to determine this, with specific knowledge of the implementation. The proposal is that loopback devices report themselves like any other provider, but a filtering mechanism will be added to the interface, for use by the app to determine the level of loopback support. The most natural solution is to add a domain attribute that describes loopback support. This requires an ABI bump, which could target the end of the year release. > * Suggested ways to implement wait support for a shared memory provider. Did not have time to discuss. > * Location(s) of libfabric and fabtests packages. There are developers who build and test packages on the OFA server. Whether the OFIWG hosts the packages on the server, they will need to be copied there anyway as part of the OFED testing. For convenience, EWG members have asked that packages also be copied to the OFA download directory. A separate email discussion for this will be started. - Sean _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
