From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH] net/mlx: support firmware version query
Date: Wed, 6 Feb 2019 14:27:26 -0800
Message-ID: <20190206142726.7f5395cc@hermes.lan>
References: <20190206215909.30147-1-thomas@monjalon.net>
 <20190206141648.5f2d6a99@hermes.lan> <1561267.IqWJBFvPPj@xps>
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: Thomas Monjalon <thomas@monjalon.net>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com
 [209.85.215.195]) by dpdk.org (Postfix) with ESMTP id 64EF31B464
 for <dev@dpdk.org>; Wed,  6 Feb 2019 23:27:35 +0100 (CET)
Received: by mail-pg1-f195.google.com with SMTP id z11so3586855pgu.0
 for <dev@dpdk.org>; Wed, 06 Feb 2019 14:27:35 -0800 (PST)
In-Reply-To: <1561267.IqWJBFvPPj@xps>
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>

On Wed, 06 Feb 2019 23:23:07 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:

> 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.

The nested devices are not visible in testpmd (or other
applications that iterate over ports).