Re: [PATCH 3/4] infiniband-diags: properly resolve node guids

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Tue, Jul 12, 2011 at 04:52:50PM -0700, Ira Weiny wrote:

> > And, I don't think there is anything wrong with reporting a whole
> > switch node either - but the portGUID should be identifier, not the
> > node GUID.
> 
> Ok, I see where you are coming from but I am not sure I agree with you.
> 
> I guess I don't see an issue with using NodeGUID as a unique ID for a node.
> The node-name-map functionality in complib provides a translation from
> NodeGUID's to names.  (For those NodeDescriptions which are not programmable
> in FW.)

Well, I never liked that functionality in complib either ;) I'd have
been much happier if portGUID was the key. That avoids the ambiguity
of refering to mulitple ports using a single name, and avoids needing
to do a NodeInfoRecord query followed by a PathRecord query to setup
a path to a user defined name.

> > Ie, admins should never need to know what the node GUID is, and they
> > certainly should not be required to keep track of both a port GUID and
> > a node GUID for every CA just to use one tool or another.
> 
> I see your point.  However, I don't think it is correct to consider
> a PortGUID a representation of a node.  Specifically what does
> "iblinkinfo" print for a [E]SP0 PortGUID?  (for example when not run
> with "--all-ports"). iblinkinfo and by derivation ibqueryerrors
> reports information for all the links (all the ports) on a node.

A tool should behave exactly the same if it is given a GID, port GUID, LID
or directed route path (and perhaps in future an IP address that would
be ARP'd to get a GID). Not supporting those address options in a tool
goes against the UI design of every other tool in the diags suite.

For a program like iblinkinfo I think it would be appropriate to show
the entire switch, and to show only the single CA port. IIRC this is
what the ibtool version of iblinkinfo does.

If you think displaying an entire CA node is appropriate then use the
SA to translate from a standard end port identifier to a node GUID and
then use the SA to enumerate all the CA node end ports. Don't require
the user to enter a node identifier just to avoid some processing in a
diag tool :(

The point is, nobody should be expected to know what node GUIDs are,
we want people to refer to fabric devices by GID, LID or DR path,
which are all more natural.

> Frankly this is a part of the spec which I consider convoluted and perhaps
> there is no good way around it.  Specifically querying NodeInfo on a Node
> changes depending on which port the NodeInfo was requested on.  This just
> seems wrong.  ;-)

NodeInfo and the NodeGUID exist in the form they do to make discovery
work, and they work well in that capacity.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html