Re: [PATCH] app/testpmd: format dump information of module EEPROM

[Bruce Richardson <bruce.richardson@intel.com>]

On Wed, Feb 16, 2022 at 09:45:33AM +0100, Thomas Monjalon wrote:
> 16/02/2022 09:03, David Marchand:
> > On Wed, Feb 16, 2022 at 3:27 AM Zhang, RobinX <robinx.zhang@intel.com> wrote:
> > > The idea behind this is to monitor the quality of the link in the field during testpmd operations.
> > > It is supported in Linux driver with ethtool command "ethtool -m xxx", but missing in DPDK.
> 
> That's why the bifurcated model used by mlx drivers is so much valuable:
> you can use such ethtool command while using DPDK.
> 
> > > This feature is requested by customer 6WIND and we have been told this is highly important in production.
> > > 6WIND also mentioned some other customers: NEC, EOLO and Open Systems.
> > > Similar request also received from customer CheckPoint.
> > >
> > > > > What do you think to have this as a sample application?
> > > >
> > > > It can be in the directory app/ maybe.
> > >
> > > Base on the above background, I'm not sure if customer could accept this feature as a sample application.
> > 
> > Rather than add this in testpmd or a sample app, does it make sense to
> > provide this info as a telemetry command?
> > This makes those status information available in any dpdk application.
> 
> +1
> Production code should be in a DPDK library.
> 
> > There is a "but" with this proposal.
> > Existing applications might have been calling "eeprom" ethdev API
> > already, and adding such a callback in telemetry could lead to
> > concurrency issues.
> > 
> > I see that we have other telemetry callbacks for stats, link status
> > which might already have the issue.
> 
> You mean there is no lock protection?
> Neither in the API, nor in telemetry?
>
For reporting out stats or link status, I'm not sure a lock should ever be
needed since both are just read-only operations. Therefore, I don't believe
we have a general issue here.

/Bruce