[ofiwg] Can fi_getname return different addrlen on different EPs?

[Hefty, Sean]

> > I’ve got a question regarding fi_getname spec. It is said that
> fi_getname may return –FI_ETOOSMALL if the provided address storage is not
> enough and the addrlen in/out parameter will be updated with correct size.
> The question is: is there implicit demand for all endpoints to return the
> same addrlen?

Good point, this may be the case when dealing with a single provider.

> Calls to fi_getinfo() returns a struct fi_info object that has three
> relevant fields: addr_format, src_addrlen, and dest_addrlen (oddly this
> implies the possibility of the src and destination addresses can be of
> different length but not different types...).  This info object is used as

Yeah, this is odd.  A single addrlen field probably may have been sufficient.  But I can envision a case where the destination address carries routing information that a local address would not need.

> a parameter to both fi_domain() and fi_endpoint()/fi_passive_ep().
> Presumably all the addresses that could be returned from fi_getname()
> should have a type that matches info->addr_format and a length that
> matches info->src_addrlen.
> 
> > It seems that it has to be the case since the call fi_av_insert takes
> pointer to the storage of several addresses and a single addrlen argument.
> Should this be directly noted in the man pages?

Technically, there shouldn't need to be this requirement.  The provider does need to somehow determine the size of the provided addresses, possibly through some provider specific mechanism.  For example, it is possible to mix sockaddr_in and sockadr_in6, assuming a fixed size for each.  A provider would just need to encode the size of the address within the address itself.

> > I know that this sounds weird that a lower level provider has variable
> address length but this happens (particularly, this is the case with
> Mellanox MXM library).
> 
> Does MXM multiple address formats that cannot be unified in some way?  Or
> is it more like having a "struct sockaddr" or "struct sockaddr_storage",
> where it can represent multiple address types but in a unified manner?

If the MXM addresses are opaque, an OFI provider could embed them within a structure that also carries the size.

- Sean