From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH] net/mlx: support firmware version query
Date: Wed, 06 Feb 2019 23:23:07 +0100
Message-ID: <1561267.IqWJBFvPPj@xps>
References: <20190206215909.30147-1-thomas@monjalon.net>
 <20190206141648.5f2d6a99@hermes.lan>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: Matan Azrad <matan@mellanox.com>, Shahaf Shuler <shahafs@mellanox.com>,
 Yongseok Koh <yskoh@mellanox.com>, dev@dpdk.org
To: Stephen Hemminger <stephen@networkplumber.org>
Return-path: <dev-bounces@dpdk.org>
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
 [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 7F7011B483
 for <dev@dpdk.org>; Wed,  6 Feb 2019 23:23:10 +0100 (CET)
In-Reply-To: <20190206141648.5f2d6a99@hermes.lan>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

06/02/2019 23:16, Stephen Hemminger:
> On Wed,  6 Feb 2019 22:59:09 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> > The API function rte_eth_dev_fw_version_get() is querying drivers
> > via the operation callback fw_version_get().
> > The implementation of this operation is added for mlx4 and mlx5.
> > Both functions are copying the same ibverbs field fw_ver
> > which is retrieved when calling ibv_query_device[_ex]()
> > during the port probing.
> > 
> > It is tested with command "drvinfo" of examples/ethtool/.
> > 
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> 
> Looks good, but hard to test because:
>   * testpmd doesn't report it

Yes, good idea, we should do this query somewhere in testpmd.
Can be a separate command or part of some other infos.

>   * with netvsc (and failsafe) the device is owned and not visible
> 
> Fixing testpmd is not hard, but what is best way to handle
> the nested device situation.

I am not sure we want to expose such info via failsafe or bonding.
If we are interested to know the underlying hardware, we should
access directly to the nested device.