From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnaldo Carvalho de Melo Subject: Re: consistency for statistics with XDP mode Date: Mon, 3 Dec 2018 16:41:01 -0300 Message-ID: <20181203194101.GD18717@kernel.org> References: <004d9dfec69c910f5677e5a2f7cf6e15b0dddee2.camel@mellanox.com> <20181201122252.54833841@redhat.com> <44106f83-a2dc-67d8-4b98-20837d2618be@gmail.com> <20181203.113001.1705527415987837525.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dsahern@gmail.com, brouer@redhat.com, saeedm@mellanox.com, mst@redhat.com, toke@toke.dk, netdev@vger.kernel.org, pstaszewski@itcare.pl, jasowang@redhat.com To: David Miller Return-path: Received: from mail.kernel.org ([198.145.29.99]:56764 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725958AbeLCTlF (ORCPT ); Mon, 3 Dec 2018 14:41:05 -0500 Content-Disposition: inline In-Reply-To: <20181203.113001.1705527415987837525.davem@davemloft.net> Sender: netdev-owner@vger.kernel.org List-ID: Em Mon, Dec 03, 2018 at 11:30:01AM -0800, David Miller escreveu: > From: David Ahern > Date: Mon, 3 Dec 2018 08:45:12 -0700 > > > On 12/1/18 4:22 AM, Jesper Dangaard Brouer wrote: > >> 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. > > > > sure and both tc and iptables have counters that can see the dropped > > packets. A counter in the driver level stats ("xdp_drop" is fine with > > with me). > > Part of the problem I have with this kind of logic is we take the choice > away from the XDP program. > > If I feel that the xdp_drop counter bump is too much overhead during a > DDoS attack and I want to avoid it, you don't give me a choice in the > matter. > > If I want to represent the statistics for that event differently, you > also give me no choice about it. > > Really, if XDP_DROP is returned, zero resources should be devoted to > the frame past that point. > > I know you want to live in this magical world where XDP stuff behaves > like the existing stack and give you all of the visibility to events > and objects. > > But that is your choice. > > Please give others the choice to not live in that world and allow XDP > programs to live in their own entirely different environment, with > custom statistics and complete control over how counters are > incremented and how objects are used and represented, if they choose > to do so. > > XDP is about choice. Coming out of the blue...: the presence of a "struct xdp_stats" in the XDP program BPF object file .BTF section, one could query and the parse to figure out what stats, if any, are provided. /me goes back to tweaking his btf_loader in pahole... :-) - Arnaldo