From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DBEB2C433FE for ; Mon, 8 Nov 2021 13:21:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C297161381 for ; Mon, 8 Nov 2021 13:21:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239899AbhKHNYg (ORCPT ); Mon, 8 Nov 2021 08:24:36 -0500 Received: from mga02.intel.com ([134.134.136.20]:65453 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239890AbhKHNYg (ORCPT ); Mon, 8 Nov 2021 08:24:36 -0500 X-IronPort-AV: E=McAfee;i="6200,9189,10161"; a="219420950" X-IronPort-AV: E=Sophos;i="5.87,218,1631602800"; d="scan'208";a="219420950" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Nov 2021 05:21:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,218,1631602800"; d="scan'208";a="491211437" Received: from irvmail001.ir.intel.com ([10.43.11.63]) by orsmga007.jf.intel.com with ESMTP; 08 Nov 2021 05:21:37 -0800 Received: from baltimore.igk.intel.com (baltimore.igk.intel.com [10.102.21.1]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id 1A8DLXuM005812; Mon, 8 Nov 2021 13:21:33 GMT From: Alexander Lobakin To: =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= Cc: Alexander Lobakin , Saeed Mahameed , Jakub Kicinski , "David S. Miller" , Jesse Brandeburg , Lukasz Czapnik , Marcin Kubiak , Michal Kubiak , Michal Swiatkowski , Jonathan Corbet , Netanel Belgazal , Arthur Kiyanovski , Guy Tzalik , Saeed Bishara , Ioana Ciornei , Claudiu Manoil , Thomas Petazzoni , Marcin Wojtas , Russell King , Edward Cree , Martin Habets , "Michael S. Tsirkin" , Jason Wang , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , KP Singh , Shay Agroskin , Sameeh Jubran , Alexander Duyck , Danielle Ratson , Ido Schimmel , Andrew Lunn , Vladyslav Tarasiuk , Arnd Bergmann , Andrew Morton , Jian Shen , Petr Vorel , Dan Murphy , Yangbo Lu , Michal Kubecek , Zheng Yongjun , Heiner Kallweit , YueHaibing , Johannes Berg , Maciej Fijalkowski , netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, bpf@vger.kernel.org Subject: Re: [PATCH net-next 03/21] ethtool, stats: introduce standard XDP statistics Date: Mon, 8 Nov 2021 14:21:13 +0100 Message-Id: <20211108132113.5152-1-alexandr.lobakin@intel.com> X-Mailer: git-send-email 2.33.1 In-Reply-To: <87v912ri7h.fsf@toke.dk> References: <20210803163641.3743-1-alexandr.lobakin@intel.com> <20210803163641.3743-4-alexandr.lobakin@intel.com> <20210803134900.578b4c37@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20211026092323.165-1-alexandr.lobakin@intel.com> <20211105164453.29102-1-alexandr.lobakin@intel.com> <87v912ri7h.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Toke Høiland-Jørgensen Date: Mon, 08 Nov 2021 12:37:54 +0100 > Alexander Lobakin writes: > > > From: Alexander Lobakin > > Date: Tue, 26 Oct 2021 11:23:23 +0200 > > > >> From: Saeed Mahameed > >> Date: Tue, 03 Aug 2021 16:57:22 -0700 > >> > >> [ snip ] > >> > >> > XDP is going to always be eBPF based ! why not just report such stats > >> > to a special BPF_MAP ? BPF stack can collect the stats from the driver > >> > and report them to this special MAP upon user request. > >> > >> I really dig this idea now. How do you see it? > >> as a key and its value as a value or ...? > > > > Ideas, suggestions, anyone? > > I don't like the idea of putting statistics in a map instead of the > regular statistics counters. Sure, for bespoke things people want to put > into their XDP programs, use a map, but for regular packet/byte > counters, update the regular counters so XDP isn't "invisible". I wanted to provide an `ip link` command for getting these stats from maps and printing them in a usual format as well, but seems like that's an unneeded overcomplication of things since using maps for "regular"/"generic" XDP stats really has no reason except for "XDP means eBPF means maps". > As Jesper pointed out, batching the updates so the global counters are > only updated once per NAPI cycle is the way to avoid a huge performance > overhead of this... That's how I do things currently, seems to work just fine. > -Toke Thanks, Al