| Message ID | 20210416022752.2814621-1-kuba@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | ethtool: add uAPI for reading standard stats | expand |
On Thu, Apr 15, 2021 at 07:27:43PM -0700, Jakub Kicinski wrote: > Continuing the effort of providing a unified access method > to standard stats, and explicitly tying the definitions to > the standards this series adds an API for general stats > which do no fit into more targeted control APIs. > > There is nothing clever here, just a netlink API for dumping > statistics defined by standards and RFCs which today end up > in ethtool -S under infinite variations of names. > > This series adds basic IEEE stats (for PHY, MAC, Ctrl frames) > and RMON stats. AFAICT other RFCs only duplicate the IEEE > stats. > > This series does _not_ add a netlink API to read driver-defined > stats. There seems to be little to gain from moving that part > to netlink. > > The netlink message format is very simple, and aims to allow > adding stats and groups with no changes to user tooling (which > IIUC is expected for ethtool). > > On user space side we can re-use -S, and make it dump > standard stats if --groups are defined. Jakub, do you have a link for the user space patches? I would like to test it with mlxsw given you already patched it (thanks!). > > $ ethtool -S eth0 --groups eth-phy eth-mac eth-ctrl rmon Given that you have now standardized these stats, do you plan to feed them into some monitoring system? For example, Prometheus has an ethtool exporter [1] and now I see that support is also being added to node_exporter [2] where it really belongs. They obviously mentioned [3] the problem with lack of standardization: "There is also almost no standardization, so if you use multiple network card vendors, you have to examine the data closely to find out what is useful to you and set up your alerts and dashboards accordingly." [1] https://github.com/Showmax/prometheus-ethtool-exporter [2] https://github.com/prometheus/node_exporter/pull/1832 [3] https://tech.showmax.com/2018/11/scraping-ethtool-data-into-prometheus/ > Stats for eth0: > eth-phy-SymbolErrorDuringCarrier: 0 > eth-mac-FramesTransmittedOK: 0 > eth-mac-FrameTooLongErrors: 0 > eth-ctrl-MACControlFramesTransmitted: 0 > eth-ctrl-MACControlFramesReceived: 1 > eth-ctrl-UnsupportedOpcodesReceived: 0 > rmon-etherStatsUndersizePkts: 0 > rmon-etherStatsJabbers: 0 > rmon-rx-etherStatsPkts64Octets: 1 > rmon-rx-etherStatsPkts128to255Octets: 0 > rmon-rx-etherStatsPkts1024toMaxOctets: 1 > rmon-tx-etherStatsPkts64Octets: 1 > rmon-tx-etherStatsPkts128to255Octets: 0 > rmon-tx-etherStatsPkts1024toMaxOctets: 1 > > v1: > > Driver support for mlxsw, mlx5 and bnxt included. > > Compared to the RFC I went ahead with wrapping the stats into > a 1:1 nest. Now IDs of stats can start from 0, at a cost of > slightly "careful" u64 alignment handling. > > Jakub Kicinski (9): > docs: networking: extend the statistics documentation > docs: ethtool: document standard statistics > ethtool: add a new command for reading standard stats > ethtool: add interface to read standard MAC stats > ethtool: add interface to read standard MAC Ctrl stats > ethtool: add interface to read RMON stats > mlxsw: implement ethtool standard stats > bnxt: implement ethtool standard stats > mlx5: implement ethtool standard stats > > Documentation/networking/ethtool-netlink.rst | 74 ++++ > Documentation/networking/statistics.rst | 44 +- > .../net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 125 ++++++ > .../ethernet/mellanox/mlx5/core/en_ethtool.c | 37 ++ > .../ethernet/mellanox/mlx5/core/en_stats.c | 142 +++++- > .../ethernet/mellanox/mlx5/core/en_stats.h | 10 + > .../mellanox/mlxsw/spectrum_ethtool.c | 129 ++++++ > include/linux/ethtool.h | 95 ++++ > include/uapi/linux/ethtool.h | 10 + > include/uapi/linux/ethtool_netlink.h | 137 ++++++ > net/ethtool/Makefile | 2 +- > net/ethtool/netlink.c | 10 + > net/ethtool/netlink.h | 8 + > net/ethtool/stats.c | 410 ++++++++++++++++++ > net/ethtool/strset.c | 25 ++ > 15 files changed, 1248 insertions(+), 10 deletions(-) > create mode 100644 net/ethtool/stats.c > > -- > 2.30.2 >
On Fri, 16 Apr 2021 18:44:26 +0300 Ido Schimmel wrote: > On Thu, Apr 15, 2021 at 07:27:43PM -0700, Jakub Kicinski wrote: > > Continuing the effort of providing a unified access method > > to standard stats, and explicitly tying the definitions to > > the standards this series adds an API for general stats > > which do no fit into more targeted control APIs. > > > > There is nothing clever here, just a netlink API for dumping > > statistics defined by standards and RFCs which today end up > > in ethtool -S under infinite variations of names. > > > > This series adds basic IEEE stats (for PHY, MAC, Ctrl frames) > > and RMON stats. AFAICT other RFCs only duplicate the IEEE > > stats. > > > > This series does _not_ add a netlink API to read driver-defined > > stats. There seems to be little to gain from moving that part > > to netlink. > > > > The netlink message format is very simple, and aims to allow > > adding stats and groups with no changes to user tooling (which > > IIUC is expected for ethtool). > > > > On user space side we can re-use -S, and make it dump > > standard stats if --groups are defined. > > Jakub, do you have a link for the user space patches? I would like to > test it with mlxsw given you already patched it (thanks!). Done! > > $ ethtool -S eth0 --groups eth-phy eth-mac eth-ctrl rmon > > Given that you have now standardized these stats, do you plan to feed > them into some monitoring system? Yes and no, I'm only intending to replace the internal FB ethtool scraping script with these stats.. > For example, Prometheus has an ethtool > exporter [1] and now I see that support is also being added to > node_exporter [2] where it really belongs. They obviously mentioned [3] > the problem with lack of standardization: "There is also almost no > standardization, so if you use multiple network card vendors, you have > to examine the data closely to find out what is useful to you and set up > your alerts and dashboards accordingly." > > [1] https://github.com/Showmax/prometheus-ethtool-exporter > [2] https://github.com/prometheus/node_exporter/pull/1832 > [3] https://tech.showmax.com/2018/11/scraping-ethtool-data-into-prometheus/ Wow, are you working with those projects? We should probably let them know about the patches.
On Fri, Apr 16, 2021 at 09:08:16AM -0700, Jakub Kicinski wrote: > On Fri, 16 Apr 2021 18:44:26 +0300 Ido Schimmel wrote: > > Given that you have now standardized these stats, do you plan to feed > > them into some monitoring system? > > Yes and no, I'm only intending to replace the internal FB ethtool > scraping script with these stats.. Cool > > > For example, Prometheus has an ethtool > > exporter [1] and now I see that support is also being added to > > node_exporter [2] where it really belongs. They obviously mentioned [3] > > the problem with lack of standardization: "There is also almost no > > standardization, so if you use multiple network card vendors, you have > > to examine the data closely to find out what is useful to you and set up > > your alerts and dashboards accordingly." > > > > [1] https://github.com/Showmax/prometheus-ethtool-exporter > > [2] https://github.com/prometheus/node_exporter/pull/1832 > > [3] https://tech.showmax.com/2018/11/scraping-ethtool-data-into-prometheus/ > > Wow, are you working with those projects? We should probably let them > know about the patches. I'm mostly a user, not a contributor (wrote some exporters of my own). I'll drop a comment there once your patches are in net-next.