On Fri, 2018-11-30 at 15:30 -0500, Michael S. Tsirkin wrote: > On Fri, Nov 30, 2018 at 08:10:58PM +0000, Saeed Mahameed wrote: > > On Thu, 2018-11-22 at 18:00 +0100, Toke Høiland-Jørgensen wrote: > > > David Ahern <dsah...@gmail.com> writes: > > > > > > > On 11/22/18 1:26 AM, Toke Høiland-Jørgensen wrote: > > > > > Saeed Mahameed <sae...@mellanox.com> writes: > > > > > > > > > > > > > I'd say it sounds reasonable to include XDP in the > > > > > > > > normal > > > > > > > > traffic > > > > > > > > counters, but having the detailed XDP-specific counters > > > > > > > > is > > > > > > > > quite > > > > > > > > useful > > > > > > > > as well... So can't we do both (for all drivers)? > > > > > > > > > > > > > > > > > > > > What are you thinking ? > > > > > > reporting XDP_DROP in interface dropped counter ? > > > > > > and XDP_TX/REDIRECT in the TX counter ? > > > > > > XDP_ABORTED in the err/drop counter ? > > > > > > > > > > > > how about having a special XDP command in the .ndo_bpf that > > > > > > would query > > > > > > the standardized XDP stats ? > > > > > the XDP-specific stats are useful to have separately as well > > > > > :) > > > > > > > > > > > > > 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.
So we should count all XDP RX packets as successful rx packets i.e netdev->stats.rx_packets++; regardless of the XDP program decision ? this implies that XDP_TX packets will be counted twice once in netdev->stats.rx_packets and once in netdev->stats.tx_packets I think this is the only valid option if we are going to use standard netdev stats for XDP use cases.
