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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52C80C282E3 for ; Sat, 20 Apr 2019 20:05:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2A9DE2147C for ; Sat, 20 Apr 2019 20:05:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728055AbfDTUFJ (ORCPT ); Sat, 20 Apr 2019 16:05:09 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:38940 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727842AbfDTUFH (ORCPT ); Sat, 20 Apr 2019 16:05:07 -0400 Received: by mail-lj1-f196.google.com with SMTP id l7so7225031ljg.6 for ; Sat, 20 Apr 2019 13:05:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=DcccuybgXs5vG/OzX1Wacy9hmpQEmo3anmFFf3p6k6o=; b=CGFJHJFcNSrjzYG7HyAPMjXLkQjAqqYKpMDbK8kBmyOFXxSzp6UGY5eSBBSRqsoNol 3VC9qIIdlYQ9hxxy5ELbOf8lBVGzMGdad3U6UoVn1TSczMyh4bxbFV+XG1mwEUPLPoCw 4rxFI6JO4wLVTgg1HzYFzqGqxlR5OmVpiUWImV77/Vk7IpWTxX0OxPYZCRNQMBpVOG8a 5HFKmkk804IKLwcz3T4lGi5ra5dgk8N5FXU01T/KAv2Qq5cDY4c/5e8EtBUy7YTrXHCY gmg75PC46T4XkDbHIxOvmykuj+d3GP+v9NMvgBT4BDEYGgD7OMzoaqrnaimot9UeNwiW WW7Q== X-Gm-Message-State: APjAAAWLsS4hwfzkWPG5qkdQEkTbc/uiJ1kg0N8twjsfU0FHlSCvRiag DmiKUxPp+T6V9WrMVTWmmnUHUQ== X-Google-Smtp-Source: APXvYqxOYsBLYwyFjAFSnSiAJTZ0yV/o0FveVM1Z4jfInPt+2AGKolasgdKIZdokbddHjKnh6/GagA== X-Received: by 2002:a2e:b042:: with SMTP id d2mr5944921ljl.0.1555790704805; Sat, 20 Apr 2019 13:05:04 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id x30sm1868793ljd.38.2019.04.20.13.05.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 20 Apr 2019 13:05:03 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id AB38B1800EA; Thu, 18 Apr 2019 16:24:45 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: David Ahern , Jesper Dangaard Brouer Cc: David Miller , mst@redhat.com, makita.toshiaki@lab.ntt.co.jp, jasowang@redhat.com, netdev@vger.kernel.org, virtualization@lists.linux-foundation.org, hawk@kernel.org, Jakub Kicinski , John Fastabend , Daniel Borkmann , Saeed Mahameed , Tariq Toukan Subject: Stats for XDP actions (was: Re: [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames) In-Reply-To: References: <1548934830-2389-1-git-send-email-makita.toshiaki@lab.ntt.co.jp> <20190131101516-mutt-send-email-mst@kernel.org> <20190131.094523.2248120325911339180.davem@davemloft.net> <20190131211555.3b15c81f@carbon> <20190204125307.08492005@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 18 Apr 2019 15:24:45 +0100 Message-ID: <87tvevpf0y.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org David Ahern writes: > On 2/4/19 3:53 AM, Jesper Dangaard Brouer wrote: >> On Sat, 2 Feb 2019 14:27:26 -0700 >> David Ahern wrote: >> >>> On 1/31/19 1:15 PM, Jesper Dangaard Brouer wrote: >>>>> >>>>> David, Jesper, care to chime in where we ended up in that last thread >>>>> discussion this? >>>> >>>> IHMO packets RX and TX on a device need to be accounted, in standard >>>> counters, regardless of XDP. For XDP RX the packet is counted as RX, >>>> regardless if XDP choose to XDP_DROP. On XDP TX which is via >>>> XDP_REDIRECT or XDP_TX, the driver that transmit the packet need to >>>> account the packet in a TX counter (this if often delayed to DMA TX >>>> completion handling). We cannot break the expectation that RX and TX >>>> counter are visible to userspace stats tools. XDP should not make these >>>> packets invisible. >>> >>> Agreed. What I was pushing on that last thread was Rx, Tx and dropped >>> are all accounted by the driver in standard stats. Basically if the >>> driver touched it, the driver's counters should indicate that. >> >> Sound like we all agree (except with the dropped counter, see below). >> >> Do notice that mlx5 driver doesn't do this. It is actually rather >> confusing to use XDP on mlx5, as when XDP "consume" which include >> XDP_DROP, XDP_REDIRECT or XDP_TX, then the driver standard stats are >> not incremented... the packet is invisible to "ifconfig" stat based >> tools. > > mlx5 needs some work. As I recall it still has the bug/panic removing > xdp programs - at least I don't recall seeing a patch for it. > >> >> >>> The push back was on dropped packets and whether that counter should be >>> bumped on XDP_DROP. >> >> My opinion is the XDP_DROP action should NOT increment the drivers drop >> counter. First of all the "dropped" counter is also use for other >> stuff, which will confuse that this counter express. Second, choosing >> XDP_DROP is a policy choice, it still means it was RX-ed at the driver >> level. >> > > Understood. Hopefully in March I will get some time to come back to this > and propose an idea on what I would like to see - namely, the admin has > a config option at load time to enable driver counters versus custom map > counters. (meaning the operator of the node chooses standard stats over > strict performance.) But of course that means the drivers have the code > to collect those stats. Hi David I don't recall seeing any follow-up on this. Did you have a chance to formulate your ideas? :) -Toke