From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesper Dangaard Brouer Subject: Re: consistency for statistics with XDP mode Date: Sat, 1 Dec 2018 12:22:52 +0100 Message-ID: <20181201122252.54833841@redhat.com> References: <1d9a6548-4d1d-6624-e808-6ab0460a8655@gmail.com> <874lca2kvv.fsf@toke.dk> <651ddca3-91e0-5ad6-6afe-46aaa4bd24c9@itcare.pl> <636c1a4b9010eab5d461c13c7544a1d9e9f9ff3f.camel@mellanox.com> <87efbd1prm.fsf@toke.dk> <87r2fdm4i6.fsf@toke.dk> <9e71ad873f5c3b13bf41246d854ff4c0afd10ce9.camel@mellanox.com> <20181130152857-mutt-send-email-mst@kernel.org> <004d9dfec69c910f5677e5a2f7cf6e15b0dddee2.camel@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Cc: "mst@redhat.com" , "toke@toke.dk" , "dsahern@gmail.com" , "netdev@vger.kernel.org" , "pstaszewski@itcare.pl" , "davem@davemloft.net" , "jasowang@redhat.com" , brouer@redhat.com To: Saeed Mahameed Return-path: Received: from mx1.redhat.com ([209.132.183.28]:55475 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726424AbeLAWfU (ORCPT ); Sat, 1 Dec 2018 17:35:20 -0500 In-Reply-To: <004d9dfec69c910f5677e5a2f7cf6e15b0dddee2.camel@mellanox.com> Sender: netdev-owner@vger.kernel.org List-ID: On Fri, 30 Nov 2018 23:54:10 +0000 Saeed Mahameed wrote: > 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 writes: > > > > > > > > > On 11/22/18 1:26 AM, Toke Høiland-Jørgensen wrote: > > > > > > Saeed Mahameed 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 ? Yes. > this implies that XDP_TX packets will be counted twice once in > netdev->stats.rx_packets and once in netdev->stats.tx_packets Yes, because the packet was RX'ed on the interface, and then TX'ed on the interface. Users expect to see these packets (ac)counted. > I think this is the only valid option if we are going to use standard > netdev stats for XDP use cases. IMHO XDP_DROP should not be accounted as netdev stats drops, this is a user installed program like tc/iptables, that can also choose to drop packets. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer