[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