On Fri, 30 Nov 2018 20:41:48 -0800 Jakub Kicinski <jakub.kicin...@netronome.com> wrote:
> 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. Yes, exactly. I think we are all agreeing. RX packets in the driver NAPI-poll need to be counted as we have always done in ifconfig stats. These RX counters are incremented, regardless of TC/netfilter drop the packet later. Like wise XDP is a user installed program, and a user XDP_DROP action/choice should not "hide" this packet from the drivers RX-counter (as that IMHO could be more confusing to the user). > I don't think DPDK drivers maintain "just in case" statistics, either.. I agree. Maintaining counters for everything will cause performance issues. That said if we do choose to standardize XDP stats per action, as most driver do maintain some ethtool counter anyhow, then we have to make sure this doesn't hurt performance. One simple trick is to bulk update these counters at the end of drivers napi_pool function (like most drivers do for the RX-counter stats). -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer
