On Mon, 29 Nov 2021 16:51:02 +0100 Petr Machata wrote: > Jakub Kicinski <kuba@xxxxxxxxxx> writes: > > On Sun, 28 Nov 2021 19:54:53 +0200 Ido Schimmel wrote: > >> 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. > >> 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 on > > > > Does 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 :) > >> 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?