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.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 64F04C282C4 for ; Tue, 5 Feb 2019 03:13:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2A50720830 for ; Tue, 5 Feb 2019 03:13:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="aXcd3Vic" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726480AbfBEDNX (ORCPT ); Mon, 4 Feb 2019 22:13:23 -0500 Received: from mail-pg1-f193.google.com ([209.85.215.193]:42730 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725917AbfBEDNX (ORCPT ); Mon, 4 Feb 2019 22:13:23 -0500 Received: by mail-pg1-f193.google.com with SMTP id d72so809352pga.9 for ; Mon, 04 Feb 2019 19:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1jzL1h0BSiLVGPgA2wbMjn8J4U8T2kk5//ManamHNJA=; b=aXcd3VicPhGFvgpmhAaMSLTr8XViWuZlD2t22AybGNuFa54ai2GuWuzoyRil0B8JR0 8b9xu9VfF55wmizLmllKbLir+9/9V1WjpSu370te7wE1g/yTIU+qO+iwA0xmed/VAjxB Tf1aEKJMcU9IxfUqxVTbIvlOMNBrIPfVfJyZ2fz6TICjSoocrg2TrQ3eS7Q2zhvmBP0Q Pw8m3hs8L2/ld3J11NvCMMtsqFk0GDxQEXK0K6vKxxquLBT65uJyHGobhKjoDeSRTKTJ 9YIJTXYo9xa6dNvDkmcdvyh8SnLmjeTyssPcNSgqs4BlhoralwY9XnxPi1r3i/6xg3IQ Ty2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1jzL1h0BSiLVGPgA2wbMjn8J4U8T2kk5//ManamHNJA=; b=ikOdM05WB82Jg+5gFobYpbn4/6edFuuaagd3ncjXhGASGsKCOS+oC/SmFl+P9Xiskt DvQVSss861XiYxItWH6SPAG37bIIHIrCWsC4H1GPMCFod4HZ4I6ZAy0E5dDKNSnIu4yc PQYebS5qcXSAs2fuiiu0LABi5jLWLOYLvvL8xa28MhgeT5KDMo/vAICdZb4wToCXBcS+ yuc1an3GKD11p9ORlFtZCiakewlDfOGCjqdiiI8N6btbx0hPNL9sdI8hEcExSYgvF/zV PzLJTjYsJKNgYrukakQoEPdCUDfV/KMxunyWt3En6Z08zJ4aFSfuaCT2vnOM61YPDIdH blhw== X-Gm-Message-State: AHQUAub1aok8j+tjj7sPPg8UGF+Yvq3SG1MKIeKWMv7CdQzbXg7G+IHY ir36jXkwjWOm+YCr55LbS0Q= X-Google-Smtp-Source: AHgI3IZKAoGTdYh1XV4aiJEGDhqyjl2ckV/esn/hZbAIpFvq4Z9w34hx9ZJy0oALJhP6Nu508ElaNQ== X-Received: by 2002:a63:4456:: with SMTP id t22mr2593388pgk.0.1549336402687; Mon, 04 Feb 2019 19:13:22 -0800 (PST) Received: from [172.27.227.2] ([216.129.126.118]) by smtp.googlemail.com with ESMTPSA id o84sm2248954pfi.172.2019.02.04.19.13.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Feb 2019 19:13:21 -0800 (PST) Subject: Re: [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames To: 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, =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , Jakub Kicinski , John Fastabend , Daniel Borkmann , Saeed Mahameed , Tariq Toukan 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> From: David Ahern Message-ID: Date: Mon, 4 Feb 2019 19:13:18 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190204125307.08492005@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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.