From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: consistency for statistics with XDP mode Date: Mon, 03 Dec 2018 11:30:01 -0800 (PST) Message-ID: <20181203.113001.1705527415987837525.davem@davemloft.net> References: <004d9dfec69c910f5677e5a2f7cf6e15b0dddee2.camel@mellanox.com> <20181201122252.54833841@redhat.com> <44106f83-a2dc-67d8-4b98-20837d2618be@gmail.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: brouer@redhat.com, saeedm@mellanox.com, mst@redhat.com, toke@toke.dk, netdev@vger.kernel.org, pstaszewski@itcare.pl, jasowang@redhat.com To: dsahern@gmail.com Return-path: Received: from shards.monkeyblade.net ([23.128.96.9]:44538 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725885AbeLCTaK (ORCPT ); Mon, 3 Dec 2018 14:30:10 -0500 In-Reply-To: <44106f83-a2dc-67d8-4b98-20837d2618be@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: 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.