On Tue, Feb 04, 2020 at 04:27:45AM +0000, Parav Pandit wrote: > > > > From: Jason Gunthorpe <jgg@xxxxxxxxxxxx> > > Sent: Monday, February 3, 2020 11:34 PM > > > > On Mon, Feb 03, 2020 at 11:31:06PM +0530, Devesh Sharma wrote: > > > On Mon, Feb 3, 2020 at 11:23 PM Jason Gunthorpe <jgg@xxxxxxxxxxxx> > > wrote: > > > > > > > > On Mon, Feb 03, 2020 at 12:52:04PM -0500, Devesh Sharma wrote: > > > > > It becomes difficult to make out from the output of ibv_devinfo if > > > > > a particular gid index is RoCE v2 or not. > > > > > > > > > > Adding a string to the output of ibv_devinfo -v to display the gid > > > > > type at the end of gid. > > > > > > > > > > The output would look something like below: > > > > > $ ibv_devinfo -v -d bnxt_re2 > > > > > hca_id: bnxt_re2 > > > > > transport: InfiniBand (0) > > > > > fw_ver: 216.0.220.0 > > > > > node_guid: b226:28ff:fed3:b0f0 > > > > > sys_image_guid: b226:28ff:fed3:b0f0 > > > > > . > > > > > . > > > > > . > > > > > . > > > > > phys_state: LINK_UP (5) > > > > > GID[ 0]: fe80::b226:28ff:fed3:b0f0, IB/RoCE v1 > > > > > GID[ 1]: fe80::b226:28ff:fed3:b0f0, RoCE v2 > > > > > GID[ 2]: ::ffff:192.170.1.101, IB/RoCE v1 > > > > > GID[ 3]: ::ffff:192.170.1.101, RoCE v2 > > > > > > > > v1 GIDs are GIDs and should never be formed as IPv6 addreses.. > > > So, V1 gids would fall back to old style of display and there will be > > > one more check for gid-type inside the loop... > > > > Yes > > > > Parav should we show both the v6 and classic format for a v2 GID? ie > > > > GID[ 3]: 0000:0000:0000:ffff:xxxx:xxxx:xxxx, RoCE v2 > > ::ffff:192.170.1.101 > > > Due to lack of support of GID's netdev, v1/v2 type info in ibv_devinfo output, most users that I know of are using non upstream show_gids script. > So changing format here shouldn't break the existing users scripts. > There may be some scripts that may find this format different. > So I think printing both is likely a more safer option. I don't understand this argument. Output from example tool (ibv_devinfo) inside libibverbs can't be considered API and we can't live in constant fear that some user script will break. Of course, we will try to keep it stable, but there is no such promise. Thanks > > > Lets also supress the 'IB/RoCE v1' string on !roce device. IB only has one GID > > type, there is no reason to print anything > > > > Jason