On Fri, 30 Nov 2018 13:35:53 -0700, David Ahern wrote: > On 11/30/18 1:30 PM, Michael S. Tsirkin wrote: > >>>> I would like to see basic packets, bytes, and dropped counters > >>>> tracked > >>>> for Rx and Tx via the standard netdev counters for all devices. > >> > >> The problem of reporting XDP_DROP in the netedev drop counter is that > >> they don't fit this counter description : "no space in linux buffers" > >> and it will be hard for the user to determine whether these drops are > >> coming from XDP or because no buffer is available, which will make it > >> impossible to estimate packet rate performance without looking at > >> ethtool stats. > >> And reporting XDP_DROP in the netdev rx packets counter is somehow > >> misleading.. since those packets never made it out of this driver.. > >> > >> > >> And reporting XDP_DROP in the netdev rx packets counter is somehow > >> misleading.. since those packets never made it out of this driver.. > > > > I think I agree. XDP needs minimal overhead - if user wants to do > > counters then user can via maps. And in a sense XDP dropping packet > > is much like e.g. TCP dropping packet - it is not counted > > against the driver since it's not driver's fault. > > > > XDP dropping a packet is completely different. > > stats are important. packets disappearing with no counters -- standard > counters visible by standard tools -- is a user nightmare. If the > agreement is for XDP drops to be in driver level (e.g., xdp_drop) that > is fine since it is still retrievable by ethtool -S (existing APIs and > existing tools).
I don't think that's completely fair. Disappearing packets are a nightmare, but if the user installed a program which silently drops packets without incrementing any counter it's their own fault. If cls_bpf returns STOLEN or TRAP, I don't think that's gonna get counted anywhere. I don't think DPDK drivers maintain "just in case" statistics, either..
