On Fri, 8 Jul 2011 15:55:10 -0700 Jason Gunthorpe <[email protected]> wrote:
> On Fri, Jul 08, 2011 at 03:29:53PM -0700, Ira Weiny wrote: > > On Fri, 8 Jul 2011 14:59:01 -0700 > > Hal Rosenstock <[email protected]> wrote: > > > > > On 7/8/2011 5:50 PM, Jason Gunthorpe wrote: > > > > On Fri, Jul 08, 2011 at 05:42:38PM -0400, Hal Rosenstock wrote: > > > > > > > >> Should the request just be a GET rather than GET_TABLE and avoid this > > > >> check ? I don't think multiple nodes can register with same Node GUID, > > > >> can they ? Also, I think it makes eliminates this check and the missing > > > >> 0 check. > > > > > > > > Multiport HCAs should (and do..) show up with multiple node > > > > records. There is one node record per end port, not per node. This is > > > > why using node GUID as an end port identifier is a bad choice. > > > > It is _not_ a bad choice if you are looking for a "node". > > 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. > What does it mean? > Operate on a random end port of that node? For some queries, like NodeInfo, yes that is all we need. > All end ports? Yes, why not? While this particular patch only supports the fist port found. That will support 90% of the fabrics out there which have a single port of an HCA connected to a fabric. That is why I added the warning message indicating there was a problem, as well as responding to Hal that further work would be required. > Just fail with error? Only if you can't resolve what the user is looking for. > > 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? 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. > > > > Before this patch, it did used to use the port GUID for this. > > > > The point of this patch is to do the right thing when the user is > > requesting a node they want information about. The next step is to > > accept NodeDescription and use that from the NodeRecord as a key. > > Well, it looks like this is a bug fix for both iblinkinfo and > ibqueryerrors, eg they seem to be documented to accept node GUIDs but > were treating them as port GUIDs in one place and node GUIDs in > another. Yes this was based on the assumption that PortGUID of [E]SP0 == node GUID, which AFAIK works on all current switches, but is wrong. This was "ok" when iblinkinfo and ibqueryerrors only supported switches. I wanted to expand them. > Though please update the -S section of the man page for > iblinkinfo to reflect the GUID is a node GUID.. This was included as part of the next patch 3/4 "infiniband-diags: libibnetdisc/iblinkinfo Allow for a partial fabric query centered around a CA" Ira > > Jason > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ira Weiny Math Programmer/Computer Scientist Lawrence Livermore National Lab 925-423-8008 [email protected] -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
