On Thu, Nov 07, 2024 at 11:30:23AM +0000, Vadim Fedorenko wrote: > On 07/11/2024 08:23, Leon Romanovsky wrote: > > On Wed, Nov 06, 2024 at 04:09:58PM -0800, Jakub Kicinski wrote: > > > On Wed, 6 Nov 2024 18:36:16 +0100 Andrew Lunn wrote: > > > > > How would this be done in the PCI core? As far as I can tell, all > > > > > these registers are device-specific and live in some device BAR. > > > > > > > > Is this a licences PCIe core? > > > > > > > > Could the same statistics appear in other devices which licence the > > > > same core? Maybe this needs pulling out into a helper? > > > > > > The core is licensed but I believe the _USER in the defines names means > > > the stats sit in the integration logic not the licensed IP. I could be > > > wrong. > > > > > > > If this is true, other uses of this core might not be networking > > > > hardware, so ethtool -S would not be the best interfaces. Then they > > > > should appear in debugfs? > > > > > > I tried to push back on adding PCIe config to network tooling, > > > and nobody listened. Look at all the PCI stuff in devlink params. > > > Some vendors dump PCIe signal integrity into ethtool -S > > > > Can you please give an example? I grepped various keywords and didn't > > find anything suspicious. > > Hmm... Ohh, I looked in some other place. > > [root@host ~]# ethtool -i eth0 | grep driver > driver: mlx5_core > [root@host ~]# ethtool -S eth0 | grep pci > rx_pci_signal_integrity: 1 > tx_pci_signal_integrity: 1471 > outbound_pci_stalled_rd: 0 > outbound_pci_stalled_wr: 0 > outbound_pci_stalled_rd_events: 0 > outbound_pci_stalled_wr_events: 0 > > Isn't it a PCIe statistics? I didn't do full archaeological research and stopped at 2017 there these counters were updated to use new API, but it looks like they there from stone age. It was a mistake to put it there and they should be moved to PCI core together with other hundreds debug counters which ConnectX devices have but don't expose yet. Thanks
