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