On Wed, 06 Feb 2019 23:23:07 +0100 Thomas Monjalon <tho...@monjalon.net> wrote:
> 06/02/2019 23:16, Stephen Hemminger: > > On Wed, 6 Feb 2019 22:59:09 +0100 > > Thomas Monjalon <tho...@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 <tho...@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).