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. > > > for ease in accounting as well as speed and simplicity for bumping > > > counters for virtual devices from bpf helpers. > > > > > > From there, the XDP ones can be in the driver private stats as they > > > are > > > currently but with some consistency across drivers for redirects, > > > drops, > > > any thing else. > > > > > > So not a radical departure from where we are today, just getting > > > the > > > agreement for consistency and driver owners to make the changes. > > > > Sounds good to me :) > > > > -Toke
