On Thu, 2007-03-29 at 01:08, Michael S. Tsirkin wrote: > > > > > I expect ibnetdiscover can do this, but was unable to grok > > > > > the output syntax. > > > > > > > > I'll explain once I have the answer to the above question. > > > > Search for "H-<GUID in hex>", where GUID in hex is the node GUID, in the > > output of ibnetdiscover. [1] to the right of it indicates it is port 1. > > > > So for example, > > Switch 24 "S-005442ba00003080" # "ISR9024 Voltaire" base port 0 > > lid 6 lmc 0 > > [22] "H-0008f10403961354"[1] # "MT23108 InfiniHost Mellanox > > Technologies" lid 4 > > > > It is listed under the switch it is attached to and in the right hand > > side is the LID of the switch which in this case is 6. > > And how do I know the switch port here?
It's the port on the left hand side (e.g. 22 in this case). > Hal, where does this syntax come from? Some legacy script? It originated with a proprietary tool a long time ago and has been enhanced from there to add additional information as time went on. > How about fixing this tool to provide a sane, I think it is sane output. > tabulated output, with > a top self-documenting header, and flags to select specific rows/colums? > > I envision something a la ps: > > type guid port remote_lid remote_port description I'd like to understand more of what you intend and why the current format is insufficient. > Would such a patch be accepted? Such a patch would need to include all the affected tools, not just ibnetdiscover or alternatively have an option for this new output format with the existing format as a default. I think the latter would be needed for backwards compatibility. -- Hal _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
