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

Ira Weiny
2011-07-12T23:52:50Z

On Mon, 11 Jul 2011 14:18:43 -0700
Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:

> On Mon, Jul 11, 2011 at 02:06:02PM -0700, Ira Weiny wrote:
>
> > > But very few diags seem to be designed around the idea that they will
> > > operate on a bundle of end ports (eg a node), they tend to be one end
> > > port only, so asking for a "node" is nonsense.
> >
> > Why do you object to tools which report information for an entire
> > node? Nodes, specifically switches, are much more manageable chunks
> > than an entire fabric.
>
> I don't object to that, I'm just pointing out that most of the tools
> aren't like that today, and many don't have a clear way to format
> their output in a multi-end-port format.
>
> 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.)

>
> > > I don't like this trend to make node GUID the default GUID input
> > > format for diags. FWIW, ibtool consistently uses port GUID as the
> > > default GUID type for all end port specifications.
> >
> > I am not proposing this for all tools. Why shouldn't a user be able to query
> > more than a single port at a time in some "higher level" tools?
>
> I'd much rather see only portGUID used as an argument and a
> --all-ports option that would report all HCA ports - by automatically
> doing the necessary SA operations to find them. This is much better
> than having to force an admin to use port GUIDs in some tools and node
> GUID in (very few) other tools.
>
> 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.

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. ;-)

To me when I wrote iblinkinfo it just made sense that you would request
information about a particular node (specifically switch). Otherwise the
output would be pretty stupid for a switch PortGUID. Therefore the NodeGUID
seemed reasonable.

>
> > Also how would you propose to resolve a query via NodeDescription?
> > Put yourself in the shoes of the administrator who is trying to
> > manage 1000's of "nodes" in a system. Names are much easier to deal
> > with than GUID's and LID's.
>
> I've no objection to searching by node description, as long as the
> tool supports a multiple end port output format. Don't see what this
> has to do with node GUID support :)

Only that searching for NodeRecords to resolve nodes on the fabric is a
reasonable way to go. This patch moves in that direction.

Ira

>
> Jason

--
Ira Weiny
Math Programmer/Computer Scientist
Lawrence Livermore National Lab
925-423-8008
weiny2-i2BcT+NCU+M@public.gmane.org