From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
To: Ira Weiny <weiny2-i2BcT+NCU+M@public.gmane.org>
Cc: Hal Rosenstock
<hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>,
"linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 3/4] infiniband-diags: properly resolve node guids
Date: Mon, 11 Jul 2011 15:18:43 -0600 [thread overview]
Message-ID: <20110711211843.GD10216@obsidianresearch.com> (raw)
In-Reply-To: <20110711140602.9ae3943e.weiny2-i2BcT+NCU+M@public.gmane.org>
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.
> > 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.
> 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 :)
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
next prev parent reply other threads:[~2011-07-11 21:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-05 19:08 [PATCH 3/4] infiniband-diags: properly resolve node guids Ira Weiny
[not found] ` <20110705120815.3cc7d59b.weiny2-i2BcT+NCU+M@public.gmane.org>
2011-07-08 21:42 ` Hal Rosenstock
[not found] ` <4E1779CE.9030502-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2011-07-08 21:50 ` Jason Gunthorpe
[not found] ` <20110708215046.GB10216-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2011-07-08 21:59 ` Hal Rosenstock
[not found] ` <4E177DA5.9030600-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2011-07-08 22:29 ` Ira Weiny
[not found] ` <20110708152953.0063fb7b.weiny2-i2BcT+NCU+M@public.gmane.org>
2011-07-08 22:55 ` Jason Gunthorpe
[not found] ` <20110708225510.GC10216-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2011-07-11 21:06 ` Ira Weiny
[not found] ` <20110711140602.9ae3943e.weiny2-i2BcT+NCU+M@public.gmane.org>
2011-07-11 21:18 ` Jason Gunthorpe [this message]
[not found] ` <20110711211843.GD10216-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2011-07-12 23:52 ` Ira Weiny
[not found] ` <20110712165250.a3cb9d47.weiny2-i2BcT+NCU+M@public.gmane.org>
2011-07-13 5:09 ` Jason Gunthorpe
2011-07-11 19:02 ` Hal Rosenstock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110711211843.GD10216@obsidianresearch.com \
--to=jgunthorpe-epgobjl8dl3ta4ec/59zmfatqe2ktcn/@public.gmane.org \
--cc=hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=weiny2-i2BcT+NCU+M@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox