On Tue, Feb 4, 2020 at 12:55 PM Parav Pandit <parav@xxxxxxxxxxxx> wrote:
>
> Hi Leon,
>
> > From: Leon Romanovsky <leon@xxxxxxxxxx>
> > Sent: Tuesday, February 4, 2020 12:48 PM
> >
> > 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.
> >
> I agree with your point that ibv_devinfo output is not an API.
> I haven't come across a user who uses ibv_devinfo output as an API given lack of info in it.
> I really do not have any strong opinion to keep both format or single format.
To it looks dirty, if the tool would print both things would look
something like:
phys_state: LINK_UP (5)
GID[ 0]:
fe80:0000:0000:0000:b226:28ff:fed3:b0f0, IB/RoCE v1
GID[ 1]:
fe80:0000:0000:0000:b226:28ff:fed3:b0f0, RoCE v2
GID[ 1]: fe80::b226:28ff:fed3:b0f0
GID[ 2]:
0000:0000:0000:0000:0000:ffff:c0aa:0165, IB/RoCE v1
GID[ 3]:
0000:0000:0000:0000:0000:ffff:c0aa:0165, RoCE v2
GID[ 3]: ::ffff:192.170.1.101
