On Mon, 29 Nov 2021 14:59:53 +0100 Jesper Dangaard Brouer wrote: > Hmm... I don't agree here. IMHO the BPF-program's *choice* to drop (via > XDP_DROP) should NOT share the counter with the driver-related drops. > > The driver-related drops must be accounted separate. +1 FWIW. The Tx stat is a little misleading because it differs from the definition of our other tx stats which mean _successfully_ transmitted (and are accounted on the completion path in many drivers). In the past I've used act_*, e.g. act_tx, to indicate the stat counts returned actions, not whether the packet made it. I still wonder whether it makes sense to count the stats per-action or just have one "XDP consumed it" stat and that's it. The semantics of the action are not of interest to the admin. A firewall can drop or tx depending if it wants to send an ICMP reject or TCP RST message in response. I need to know what the application does to understand the difference, and if I do I can as well look at app stats. But I'm aware I'm not going to find much support for this position, so just saying... ;)