Re: [PATCH v2 net-next 21/26] ice: add XDP and XSK generic per-channel statistics
From: Jakub Kicinski <kuba@kernel.org>
Date: 2021-11-29 16:07:14
Also in:
bpf, linux-doc, linux-rdma, lkml
On Mon, 29 Nov 2021 16:51:02 +0100 Petr Machata wrote:
Jakub Kicinski [off-list ref] writes:quoted
On Sun, 28 Nov 2021 19:54:53 +0200 Ido Schimmel wrote:quoted
I agree. I think IFLA_STATS64 in RTM_NEWLINK should contain statistics of all the packets seen by the netdev. The breakdown into software / hardware / XDP should be reported via RTM_NEWSTATS.Hm, in the offload case "seen by the netdev" may be unclear. For the offload case I believe our recommendation was phrased more like "all packets which would be seen by the netdev if there was no routing/tc offload", right?Yes. The idea is to expose to Linux stats about traffic at conceptually corresponding objects in the HW.
Great.
quoted
quoted
Currently, for soft devices such as VLANs, bridges and GRE, user space only sees statistics of packets forwarded by software, which is quite useless when forwarding is offloaded from the kernel to hardware. Petr is working on exposing hardware statistics for such devices via rtnetlink. Unlike XDP (?), we need to be able to let user space enable / disable hardware statistics as we have a limited number of hardware counters and they can also reduce the bandwidth when enabled. We are thinking of adding a new RTM_SETSTATS for that: # ip stats set dev swp1 hw_stats onDoes it belong on the switch port? Not the netdev we want to track?Yes, it does, and is designed that way. That was just muscle memory typing that "swp1" above :) You would do e.g. "ip stats set dev swp1.200 hw_stats on" or, "dev br1", or something like that.
I see :)
quoted
quoted
For query, something like (under discussion): # ip stats show dev swp1 // all groups # ip stats show dev swp1 group link # ip stats show dev swp1 group offload // all sub-groups # ip stats show dev swp1 group offload sub-group cpu # ip stats show dev swp1 group offload sub-group hw Like other iproute2 commands, these follow the nesting of the RTM_{NEW,GET}STATS uAPI.But we do have IFLA_STATS_LINK_OFFLOAD_XSTATS, isn't it effectively the same use case?IFLA_STATS_LINK_OFFLOAD_XSTATS is a nest. Currently it carries just CPU_HIT stats. The idea is to carry HW stats as well in that group.
Hm, the expectation was that the HW stats == total - SW. I believe that still holds true for you, even if HW stats are not "complete" (e.g. user enabled them after device was already forwarding for a while). Is the concern about backward compat or such?