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 3AAD5C433F5 for ; Mon, 8 Nov 2021 18:09:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 24B1E61989 for ; Mon, 8 Nov 2021 18:09:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234999AbhKHSMA (ORCPT ); Mon, 8 Nov 2021 13:12:00 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:42524 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234952AbhKHSL7 (ORCPT ); Mon, 8 Nov 2021 13:11:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1636394953; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1cEuhXaEuhD+GKL/lBmFj9KF6WCNj/n+YccNImJPdjg=; b=RtDjLOyG+rvejCqdCpqUrTxUmiM+0yQ6Dk3aIr/ytyH3lfKVJemntMIeWjpqeMmZTJs6iR Gvqfo2dDOgzvfJCq0VagoMab4VYfHQCBk9SZXM6m4PcY7tM44lkVhYx+lkabhLWVOwpXfe 37wUPUG9ofma1X5gCwn4olEtKTvLJQY= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-432-PAZQvrTAPxeOMRyUrR75Sg-1; Mon, 08 Nov 2021 13:09:12 -0500 X-MC-Unique: PAZQvrTAPxeOMRyUrR75Sg-1 Received: by mail-ed1-f72.google.com with SMTP id t20-20020a056402525400b003e2ad6b5ee7so15611375edd.8 for ; Mon, 08 Nov 2021 10:09:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=1cEuhXaEuhD+GKL/lBmFj9KF6WCNj/n+YccNImJPdjg=; b=O/olx1k5dGemIEOA+AP5NBjap3fdIClsBkqu4y8adG+qR3xWzJV+wYiHnUJJrLjCzB ZD9220uoPbBsYKrCS92bRWTPB5nVA5nll546Pn9Cor2yTCK2e00FZUvICcaQA2P4a36J tW8WyAL9dHrRyTXcvTk3DM3lUAUVV8yGPCoapj021jaV43uGQAswGN6Met9+CPbukD+i 8OBGYrtMAoMEtOwQeNqaGjC9pMaMSMHmkLwPE70meyvM/DZasQfjHVzr4rOr+tisl4u+ +QIyoHJ7wyAahcrrWwWdiFS+b7tz8aYmBUQyeycMlmflCpyW2z0c8j6Tq3lJRIPPBYmZ cCiA== X-Gm-Message-State: AOAM531JK5psPP0wLb644+kPYOromUPZ2Yol0dRKMJNnVppnzPAvC55n NtJ6MoWHzEJJUWnEXIza4L17VzpULiEBILDPfjjhXd16qTcvnGJQm86AJM/tcYcmZVNZwbhVzPJ ab+4BEJprWUTiKS5rVu1uUOXC X-Received: by 2002:a17:907:8692:: with SMTP id qa18mr1467263ejc.7.1636394950732; Mon, 08 Nov 2021 10:09:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJyClv8tcSrI/UxXplWxRW76JXyVsa3nEi/pu2Ka0nP1mqXKVKeTujb2Aq2XU4+3KU1tY6N6lw== X-Received: by 2002:a17:907:8692:: with SMTP id qa18mr1467121ejc.7.1636394949701; Mon, 08 Nov 2021 10:09:09 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id gn16sm8739933ejc.67.2021.11.08.10.09.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Nov 2021 10:09:08 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 1A5BA18026D; Mon, 8 Nov 2021 19:09:08 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Alexander Lobakin 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 In-Reply-To: <20211108132113.5152-1-alexandr.lobakin@intel.com> 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> <20211108132113.5152-1-alexandr.lobakin@intel.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Mon, 08 Nov 2021 19:09:08 +0100 Message-ID: <87cznar03f.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Alexander Lobakin writes: > From: Toke H=C3=B8iland-J=C3=B8rgensen > Date: Mon, 08 Nov 2021 12:37:54 +0100 > >> Alexander Lobakin writes: >>=20 >> > From: Alexander Lobakin >> > Date: Tue, 26 Oct 2021 11:23:23 +0200 >> > >> >> From: Saeed Mahameed >> >> Date: Tue, 03 Aug 2021 16:57:22 -0700 >> >>=20 >> >> [ snip ] >> >>=20 >> >> > XDP is going to always be eBPF based ! why not just report such sta= ts >> >> > to a special BPF_MAP ? BPF stack can collect the stats from the dri= ver >> >> > and report them to this special MAP upon user request. >> >>=20 >> >> I really dig this idea now. How do you see it? >> >> as a key and its value as a value or ...? >> > >> > Ideas, suggestions, anyone? >>=20 >> 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". Yeah, don't really see why it would have to: to me, one of the benefits of XDP is being integrated closely with the kernel so we can have a "fast path" *without* reinventing everything... >> 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. Awesome! -Toke