On Thu, May 04, 2017 at 02:34:52AM +0200, Andrew Lunn wrote: >On Thu, May 04, 2017 at 10:05:34AM +1000, Gavin Shan wrote: >> On Wed, May 03, 2017 at 09:18:23AM -0400, David Miller wrote: >> >From: Andrew Lunn <and...@lunn.ch> >> >Date: Wed, 3 May 2017 14:47:22 +0200 >> > >> >> On Wed, May 03, 2017 at 02:44:37PM +1000, Gavin Shan wrote: >> >>> This adds ethtool command (ETHTOOL_GNCSISTATS) to retrieve the >> >>> NCSI hardware statistics. >> >> >> >> Hi Gavin >> >> >> >> I've not been following this patchset, so maybe i'm about to ask a >> >> question which has already been asked and answered. >> >> >> >> Why cannot use just use ethtool -S for this? >> > >> >Indeed, when I said to use ethtool for these NCSI hw stats I meant >> >that the "ethtool -S" be used, not some new ethtool command. >> > >> >> Thanks for the comments. Feel free to ask any questions which would >> make the code clear and better. There are couple of factors I thought >> separate command is better than ETHTOOL_GSTATS: The statistic items from >> ETHTOOL_GSTATS are variable, meaning the kernel needs provide the layout >> of the statistic items via ETHTOOL_GSSET_INFO and ETHTOOL_GSTRINGS. >> NCSI HW statistics aren't following this and their layout is fixed. > >That does not stop you from using it for a fixed layout. And what >happens when a new version of the standard is released with more >statistics? >
Correct, I don't see the difference between NCSI spec 1.01 and 1.1.0. So I assume it's pretty stable, but still have potential to change. I agree to collect NCSI HW statistic with ETHTOOL_GSTATS as I said in another thread. >> Besides, statistics for ETHTOOL_GSTATS are maintained in local MAC, >> but NCSI HW statistics are collected from NIC on far-end. So they're >> different from this point. > >You might want to take a look at what is happening with Ethernet >switches. Again, we have two sets of statistics for each port on the >switch. We have the statistics from the hardware, and statistics from >the software. Frames that come in one interface and the hardware >forwards out another interface are not seen by the software. But >frames which originate/terminate in the host, or the switch does not >know what to do with and so are passed to the host, are seen by the >software. Mellanox can tell you more. Your local and remote are not >that different. > Yeah, it makes sense. Thanks for making an example here. >> Lastly, the NCSI software statistics needs separate command. It'd >> better to have separate command for HW statistics as well, to make >> things consistent. > >Are software statistics defined in DSP0222? Since they are software, i >kind of expect you want the flexibility to add more later. The >ETHTOOL_GSSET_INFO and ETHTOOL_GSTRINGS gives you that flexibility, >without having to change ethtool. > No, they're purely software implementation, not defined in DSP0222. These statistics count the NCSI packets seen by software, not hardware. It's used for diagnosis. It's a nice suggestion to convey SW statistic with ETHTOOL_GSTATS, ETHTOOL_GSSET_INFO and ETHTOOL_GSTRINGS, for better flexibility. I'll follow this in next respin. Cheers, Gavin
