[libfabric-users] use of fi_av_straddr
Hefty, Sean
sean.hefty at intel.com
Thu Feb 11 15:56:17 PST 2016
> The user wants to know what good fi_av_straddr is, and if can be used in
> some
> way to load in entries to an av table via fi_av_insertsvc or similar.
>
> Except for, perhaps, informational output, is there any intended use
> case for fi_av_straddr?
No - this is the intended use case. It's similar to inet_ntop, except that it includes the transport level address as output as well, plus possibly quality of service or routing data.
> Could we standardize the format of this string
> such that
> irrespective of provider, it could be used as an out-of-band mechanism for
> loading
> entries in to an av using the fi_av_insertsvc?
This really isn't needed. The addr parameter passed into fi_av_straddr() can already be used as input to fi_av_insert().
Fi_av_insertsvc expects the node and service strings to be separate.
> I've had a similar request from the Intrepid folks who I recall were
> hoping to use
> the output of fi_av_straddr, to determine whether or not endpoints were
> created
> by processes on the same node.
I'd like to handle this as a separate issue. If the fi_av_straddr were defined differently -- exported separate node and service strings -- maybe the above two suggestions would work. But often the node and service strings require mappings to get to the underlying fabric address, and a reverse mapping may not be unique.
> The sockets, udp, GNI, and usnic providers return a string of format
> network_addr:portnum
> or the equivalent thereof, whereas the PSM and PSM2 providers return a
> single hex
> number.
>
> Would it be possible to standardize the output to be of form network_addr
> (possibly
> provider specific): portnum string format. The string len could remain
> specific.
> I think apps could benefit from knowing that this string could then be
> cracked and fed
> in to fi_av_insertsvc, and that the first part could be used to detect
> EP's on the
> same node.
I doubt this can be standardized. Sockets, UDP, and usNIC are all IP based. IB, OPA, and shared memory are not. IB and OPA don't really have portnums; they are just made up mappings. I don’t know what format A3Cube and BG/Q use.
At some point we will need to discuss exporting topology information, which may deal with determining which peers are local.
- Sean
More information about the Libfabric-users
mailing list